leandrof/linux
1
0
Fork 0
forked from Minki/linux
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'x86/urgent' into x86-mm

Browse Source 
Merge reason: Pick up the following two fix commits.

  2be19102b7: x86, NUMA: Fix empty memblk detection in numa_cleanup_meminfo()
  765af22da8: x86-32, NUMA: Fix ACPI NUMA init broken by recent x86-64 change

Scheduled NUMA init 32/64bit unification changes depend on these.

Signed-off-by: Tejun Heo <tj@kernel.org>
This commit is contained in:
Tejun Heo 2011-05-02 14:16:37 +02:00
commit ba67cf5cf2
3115 changed files with 12719 additions and 11505 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
CREDITS
View File

@ -1677,7 +1677,7 @@ W: http://www.codemonkey.org.uk
D: Assorted VIA x86 support.
D: 2.5 AGPGART overhaul.
D: CPUFREQ maintenance.
D: Fedora kernel maintainence.
D: Fedora kernel maintenance.
D: Misc/Other.
S: 314 Littleton Rd, Westford, MA 01886, USA
@ -3211,7 +3211,7 @@ N: James Simmons
E: jsimmons@infradead.org
E: jsimmons@users.sf.net
D: Frame buffer device maintainer
D: input layer developement
D: input layer development
D: tty/console layer
D: various mipsel devices
S: 115 Carmel Avenue
@ -3290,7 +3290,7 @@ S: USA
N: Manfred Spraul
E: manfred@colorfullife.com
W: http://www.colorfullife.com/~manfred
D: Lots of tiny hacks. Larger improvments to SysV IPC msg,
D: Lots of tiny hacks. Larger improvements to SysV IPC msg,
D: slab, pipe, select.
S: 71701 Schwieberdingen
S: Germany

2
Documentation/ABI/testing/sysfs-bus-css
View File

@ -29,7 +29,7 @@ Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
linux-s390@vger.kernel.org
Description: Contains the PIM/PAM/POM values, as reported by the
channel subsystem when last queried by the common I/O
layer (this implies that this attribute is not neccessarily
layer (this implies that this attribute is not necessarily
in sync with the values current in the channel subsystem).
Note: This is an I/O-subchannel specific attribute.
Users: s390-tools, HAL

2
Documentation/ABI/testing/sysfs-class-led
View File

@ -33,5 +33,5 @@ Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Invert the LED on/off state. This parameter is specific to
gpio and backlight triggers. In case of the backlight trigger,
it is usefull when driving a LED which is intended to indicate
it is useful when driving a LED which is intended to indicate
a device in a standby like state.

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

@ -40,7 +40,7 @@
<para>Central frequency of the channel.</para>
<para>For ISDB-T the channels are usally transmitted with an offset of 143kHz. E.g. a
<para>For ISDB-T the channels are usually transmitted with an offset of 143kHz. E.g. a
valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
the channel which is 6MHz.</para>

2
Documentation/DocBook/dvb/frontend.xml
View File

@ -139,7 +139,7 @@ consistently to the DiSEqC commands as described in the DiSEqC spec.</para>
<section id="frontend_sec_tone">
<title>SEC continuous tone</title>
<para>The continous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the
<para>The continuous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the
high/low band of a dual-band LNB. When using DiSEqC epuipment this voltage has to
be switched consistently to the DiSEqC commands as described in the DiSEqC
spec.</para>

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

@ -1763,7 +1763,7 @@ as it would be on UP.
There is a furthur optimization possible here: remember our original
cache code, where there were no reference counts and the caller simply
held the lock whenever using the object? This is still possible: if
you hold the lock, noone can delete the object, so you don't need to
you hold the lock, no one can delete the object, so you don't need to
get and put the reference count.
</para>

10
Documentation/DocBook/libata.tmpl
View File

@ -1032,7 +1032,7 @@ and other resources, etc.
<listitem>
<para>
This is indicated by ICRC bit in the ERROR register and
means that corruption occurred during data transfer. Upto
means that corruption occurred during data transfer. Up to
ATA/ATAPI-7, the standard specifies that this bit is only
applicable to UDMA transfers but ATA/ATAPI-8 draft revision
1f says that the bit may be applicable to multiword DMA and
@ -1045,10 +1045,10 @@ and other resources, etc.
<term>ABRT error during data transfer or on completion</term>
<listitem>
<para>
Upto ATA/ATAPI-7, the standard specifies that ABRT could be
Up to ATA/ATAPI-7, the standard specifies that ABRT could be
set on ICRC errors and on cases where a device is not able
to complete a command. Combined with the fact that MWDMA
and PIO transfer errors aren't allowed to use ICRC bit upto
and PIO transfer errors aren't allowed to use ICRC bit up to
ATA/ATAPI-7, it seems to imply that ABRT bit alone could
indicate tranfer errors.
</para>
@ -1122,7 +1122,7 @@ and other resources, etc.
<para>
Depending on commands, not all STATUS/ERROR bits are
applicable. These non-applicable bits are marked with
&quot;na&quot; in the output descriptions but upto ATA/ATAPI-7
&quot;na&quot; in the output descriptions but up to ATA/ATAPI-7
no definition of &quot;na&quot; can be found. However,
ATA/ATAPI-8 draft revision 1f describes &quot;N/A&quot; as
follows.
@ -1507,7 +1507,7 @@ and other resources, etc.
<listitem>
<para>
CHS set up with INITIALIZE DEVICE PARAMETERS (seldomly used)
CHS set up with INITIALIZE DEVICE PARAMETERS (seldom used)
</para>
</listitem>

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

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

12
Documentation/DocBook/mtdnand.tmpl
View File

@ -485,7 +485,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
Reed-Solomon library.
</para>
<para>
The ECC bytes must be placed immidiately after the data
The ECC bytes must be placed immediately after the data
bytes in order to make the syndrome generator work. This
is contrary to the usual layout used by software ECC. The
separation of data and out of band area is not longer
@ -629,7 +629,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
holds the bad block table. Store a pointer to the pattern
in the pattern field. Further the length of the pattern has to be
stored in len and the offset in the spare area must be given
in the offs member of the nand_bbt_descr stucture. For mirrored
in the offs member of the nand_bbt_descr structure. For mirrored
bad block tables different patterns are mandatory.</para></listitem>
<listitem><para>Table creation</para>
<para>Set the option NAND_BBT_CREATE to enable the table creation
@ -648,7 +648,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
<listitem><para>Table version control</para>
<para>Set the option NAND_BBT_VERSION to enable the table version control.
It's highly recommended to enable this for mirrored tables with write
support. It makes sure that the risk of loosing the bad block
support. It makes sure that the risk of losing the bad block
table information is reduced to the loss of the information about the
one worn out block which should be marked bad. The version is stored in
4 consecutive bytes in the spare area of the device. The position of
@ -1060,19 +1060,19 @@ data in this page</entry>
<row>
<entry>0x3D</entry>
<entry>ECC byte 21</entry>
<entry>Error correction code byte 0 of the eigth 256 Bytes of data
<entry>Error correction code byte 0 of the eighth 256 Bytes of data
in this page</entry>
</row>
<row>
<entry>0x3E</entry>
<entry>ECC byte 22</entry>
<entry>Error correction code byte 1 of the eigth 256 Bytes of data
<entry>Error correction code byte 1 of the eighth 256 Bytes of data
in this page</entry>
</row>
<row>
<entry>0x3F</entry>
<entry>ECC byte 23</entry>
<entry>Error correction code byte 2 of the eigth 256 Bytes of data
<entry>Error correction code byte 2 of the eighth 256 Bytes of data
in this page</entry>
</row>
</tbody></tgroup></informaltable>

4
Documentation/DocBook/regulator.tmpl
View File

@ -267,8 +267,8 @@
<sect1 id="machine-constraint">
<title>Constraints</title>
<para>
As well as definining the connections the machine interface
also provides constraints definining the operations that
As well as defining the connections the machine interface
also provides constraints defining the operations that
clients are allowed to perform and the parameters that may be
set. This is required since generally regulator devices will
offer more flexibility than it is safe to use on a given

2
Documentation/DocBook/uio-howto.tmpl
View File

@ -797,7 +797,7 @@ framework to set up sysfs files for this region. Simply leave it alone.
perform some initialization. After that, your hardware
starts working and will generate an interrupt as soon
as it's finished, has some data available, or needs your
attention because an error occured.
attention because an error occurred.
</para>
<para>
<filename>/dev/uioX</filename> is a read-only file. A

2
Documentation/DocBook/usb.tmpl
View File

@ -690,7 +690,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
</para><para>
This request lets kernel drivers talk to user mode code
through filesystem operations even when they don't create
a charactor or block special device.
a character or block special device.
It's also been used to do things like ask devices what
device special file should be used.
Two pre-defined ioctls are used

2
Documentation/DocBook/v4l/common.xml
View File

@ -100,7 +100,7 @@ linux-kernel@vger.kernel.org, 2002-11-20. --></para>
<para>By convention system administrators create various
character device special files with these major and minor numbers in
the <filename>/dev</filename> directory. The names recomended for the
the <filename>/dev</filename> directory. The names recommended for the
different V4L2 device types are listed in <xref linkend="devices" />.
</para>

2
Documentation/DocBook/v4l/controls.xml
View File

@ -1243,7 +1243,7 @@ values are:</entry>
</row><row><entry spanname="descr">Mutes the audio when
capturing. This is not done by muting audio hardware, which can still
produce a slight hiss, but in the encoder itself, guaranteeing a fixed
and reproducable audio bitstream. 0 = unmuted, 1 = muted.</entry>
and reproducible audio bitstream. 0 = unmuted, 1 = muted.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-encoding">

2
Documentation/DocBook/v4l/dev-subdev.xml
View File

@ -90,7 +90,7 @@
processing hardware.</para>
<figure id="pipeline-scaling">
<title>Image Format Negotation on Pipelines</title>
<title>Image Format Negotiation on Pipelines</title>
<mediaobject>
<imageobject>
<imagedata fileref="pipeline.pdf" format="PS" />

2
Documentation/DocBook/v4l/libv4l.xml
View File

@ -140,7 +140,7 @@ and is not locked sets the cid to the scaled value.
<para>int v4l2_get_control(int fd, int cid) -
This function returns a value of 0 - 65535, scaled to from the actual range
of the given v4l control id. when the cid does not exist, could not be
accessed for some reason, or some error occured 0 is returned.
accessed for some reason, or some error occurred 0 is returned.
</para></listitem>
</itemizedlist>
</section>

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

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

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

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

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

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

2
Documentation/DocBook/v4l/remote_controllers.xml
View File

@ -133,7 +133,7 @@ different IR's. Due to that, V4L2 API now specifies a standard for mapping Media
<row><entry><constant>KEY_LEFT</constant></entry><entry>Left key</entry><entry>LEFT</entry></row>
<row><entry><constant>KEY_RIGHT</constant></entry><entry>Right key</entry><entry>RIGHT</entry></row>
<row><entry><emphasis role="bold">Miscelaneous keys</emphasis></entry></row>
<row><entry><emphasis role="bold">Miscellaneous keys</emphasis></entry></row>
<row><entry><constant>KEY_DOT</constant></entry><entry>Return a dot</entry><entry>.</entry></row>
<row><entry><constant>KEY_FN</constant></entry><entry>Select a function</entry><entry>FUNCTION</entry></row>

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

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

2
Documentation/DocBook/writing-an-alsa-driver.tmpl
View File

@ -4784,7 +4784,7 @@ struct _snd_pcm_runtime {
FM registers can be directly accessed through the direct-FM API,
defined in <filename>&lt;sound/asound_fm.h&gt;</filename>. In
ALSA native mode, FM registers are accessed through
the Hardware-Dependant Device direct-FM extension API, whereas in
the Hardware-Dependent Device direct-FM extension API, whereas in
OSS compatible mode, FM registers can be accessed with the OSS
direct-FM compatible API in <filename>/dev/dmfmX</filename> device.
</para>

4
Documentation/PCI/MSI-HOWTO.txt
View File

@ -253,8 +253,8 @@ In constrast, MSI is restricted to a maximum of 32 interrupts (and
must be a power of two). In addition, the MSI interrupt vectors must
be allocated consecutively, so the system may not be able to allocate
as many vectors for MSI as it could for MSI-X. On some platforms, MSI
interrupts must all be targetted at the same set of CPUs whereas MSI-X
interrupts can all be targetted at different CPUs.
interrupts must all be targeted at the same set of CPUs whereas MSI-X
interrupts can all be targeted at different CPUs.
4.5.2 Spinlocks

2
Documentation/SecurityBugs
View File

@ -28,7 +28,7 @@ expect these delays to be short, measurable in days, not weeks or months.
A disclosure date is negotiated by the security team working with the
bug submitter as well as vendors. However, the kernel security team
holds the final say when setting a disclosure date. The timeframe for
disclosure is from immediate (esp. if it's already publically known)
disclosure is from immediate (esp. if it's already publicly known)
to a few weeks. As a basic default policy, we expect report date to
disclosure date to be on the order of 7 days.

2
Documentation/SubmittingDrivers
View File

@ -101,7 +101,7 @@ PM support: Since Linux is used on many portable and desktop systems, your
complete overview of the power management issues related to
drivers see Documentation/power/devices.txt .
Control: In general if there is active maintainance of a driver by
Control: In general if there is active maintenance of a driver by
the author then patches will be redirected to them unless
they are totally obvious and without need of checking.
If you want to be the contact and update point for the

2
Documentation/SubmittingPatches
View File

@ -729,7 +729,7 @@ Linus Torvalds's mail on the canonical patch format:
<http://lkml.org/lkml/2005/4/7/183>
Andi Kleen, "On submitting kernel patches"
Some strategies to get difficult or controversal changes in.
Some strategies to get difficult or controversial changes in.
http://halobates.de/on-submitting-patches.pdf
--

4
Documentation/arm/IXP4xx
View File

@ -36,7 +36,7 @@ Linux currently supports the following features on the IXP4xx chips:
- Timers (watchdog, OS)
The following components of the chips are not supported by Linux and
require the use of Intel's propietary CSR softare:
require the use of Intel's proprietary CSR softare:
- USB device interface
- Network interfaces (HSS, Utopia, NPEs, etc)
@ -47,7 +47,7 @@ software from:
http://developer.intel.com/design/network/products/npfamily/ixp425.htm
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY
SOFTWARE.
There are several websites that provide directions/pointers on using

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

@ -116,7 +116,7 @@ Configuration
Allows the entire memory to be checksummed before and after the
suspend to see if there has been any corruption of the contents.
Note, the time to calculate the CRC is dependant on the CPU speed
Note, the time to calculate the CRC is dependent on the CPU speed
and the size of memory. For an 64Mbyte RAM area on an 200MHz
S3C2410, this can take approximately 4 seconds to complete.

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

@ -5,7 +5,7 @@ Introduction
------------
This outlines the Samsung GPIO implementation and the architecture
specfic calls provided alongisde the drivers/gpio core.
specific calls provided alongisde the drivers/gpio core.
S3C24XX (Legacy)

4
Documentation/block/biodoc.txt
View File

@ -497,7 +497,7 @@ The scatter gather list is in the form of an array of <page, offset, len>
entries with their corresponding dma address mappings filled in at the
appropriate time. As an optimization, contiguous physical pages can be
covered by a single entry where <page> refers to the first page and <len>
covers the range of pages (upto 16 contiguous pages could be covered this
covers the range of pages (up to 16 contiguous pages could be covered this
way). There is a helper routine (blk_rq_map_sg) which drivers can use to build
the sg list.
@ -565,7 +565,7 @@ struct request {
.
int tag; /* command tag associated with request */
void *special; /* same as before */
char *buffer; /* valid only for low memory buffers upto
char *buffer; /* valid only for low memory buffers up to
current_nr_sectors */
.
.

15
Documentation/cgroups/memory.txt
View File

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

2
Documentation/cpu-hotplug.txt
View File

@ -196,7 +196,7 @@ the state as 0 when a cpu if offline and 1 when its online.
#To display the current cpu state.
#cat /sys/devices/system/cpu/cpuX/online
Q: Why cant i remove CPU0 on some systems?
Q: Why can't i remove CPU0 on some systems?
A: Some architectures may have some special dependency on a certain CPU.
For e.g in IA64 platforms we have ability to sent platform interrupts to the

2
Documentation/dell_rbu.txt
View File

@ -62,7 +62,7 @@ image file and then arrange all these packets back to back in to one single
file.
This file is then copied to /sys/class/firmware/dell_rbu/data.
Once this file gets to the driver, the driver extracts packet_size data from
the file and spreads it accross the physical memory in contiguous packet_sized
the file and spreads it across the physical memory in contiguous packet_sized
space.
This method makes sure that all the packets get to the driver in a single operation.

2
Documentation/device-mapper/dm-service-time.txt
View File

@ -37,7 +37,7 @@ Algorithm
=========
dm-service-time adds the I/O size to 'in-flight-size' when the I/O is
dispatched and substracts when completed.
dispatched and subtracts when completed.
Basically, dm-service-time selects a path having minimum service time
which is calculated by:

4
Documentation/devicetree/bindings/fb/sm501fb.txt
View File

@ -18,9 +18,9 @@ Optional properties:
- edid : verbatim EDID data block describing attached display.
Data from the detailed timing descriptor will be used to
program the display controller.
- little-endian: availiable on big endian systems, to
- little-endian: available on big endian systems, to
set different foreign endian.
- big-endian: availiable on little endian systems, to
- big-endian: available on little endian systems, to
set different foreign endian.
Example for MPC5200:

2
Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
View File

@ -15,7 +15,7 @@ Optional properties:
- gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins
(R/B#). For multi-chip devices, "n" GPIO definitions are required
according to the number of chips.
- chip-delay : chip dependent delay for transfering data from array to
- chip-delay : chip dependent delay for transferring data from array to
read registers (tR). Required if property "gpios" is not used
(R/B# pins not connected).

2
Documentation/devicetree/bindings/net/can/sja1000.txt
View File

@ -39,7 +39,7 @@ Optional properties:
- nxp,no-comparator-bypass : Allows to disable the CAN input comperator.
For futher information, please have a look to the SJA1000 data sheet.
For further information, please have a look to the SJA1000 data sheet.
Examples:

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

@ -199,7 +199,7 @@ EXAMPLE 4
EXAMPLE 5
/*
* Definition of an error interrupt (interupt type 1).
* Definition of an error interrupt (interrupt type 1).
* SoC interrupt number is 16 and the specific error
* interrupt bit in the error interrupt summary register
* is 23.

2
Documentation/dvb/README.dvb-usb
View File

@ -138,7 +138,7 @@ Hotplug is able to load the driver, when it is needed (because you plugged
in the device).
If you want to enable debug output, you have to load the driver manually and
from withing the dvb-kernel cvs repository.
from within the dvb-kernel cvs repository.
first have a look, which debug level are available:

2
Documentation/dvb/ci.txt
View File

@ -47,7 +47,7 @@ so on.
* CI modules that are supported
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The CI module support is largely dependant upon the firmware on the cards
The CI module support is largely dependent upon the firmware on the cards
Some cards do support almost all of the available CI modules. There is
nothing much that can be done in order to make additional CI modules
working with these cards.

2
Documentation/dvb/faq.txt
View File

@ -106,7 +106,7 @@ Some very frequently asked questions about linuxtv-dvb
5. The dvb_net device doesn't give me any packets at all
Run tcpdump on the dvb0_0 interface. This sets the interface
into promiscous mode so it accepts any packets from the PID
into promiscuous mode so it accepts any packets from the PID
you have configured with the dvbnet utility. Check if there
are any packets with the IP addr and MAC addr you have
configured with ifconfig.

2
Documentation/edac.txt
View File

@ -741,7 +741,7 @@ were done at i7core_edac driver. This chapter will cover those differences
As EDAC API maps the minimum unity is csrows, the driver sequencially
maps channel/dimm into different csrows.
For example, suposing the following layout:
For example, supposing the following layout:
Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400

2
Documentation/eisa.txt
View File

@ -84,7 +84,7 @@ struct eisa_driver {
id_table : an array of NULL terminated EISA id strings,
followed by an empty string. Each string can
optionally be paired with a driver-dependant value
optionally be paired with a driver-dependent value
(driver_data).
driver : a generic driver, such as described in

4
Documentation/fb/viafb.txt
View File

@ -204,7 +204,7 @@ Notes:
supported_output_devices
This read-only file contains a full ',' seperated list containing all
This read-only file contains a full ',' separated list containing all
output devices that could be available on your platform. It is likely
that not all of those have a connector on your hardware but it should
provide a good starting point to figure out which of those names match
@ -225,7 +225,7 @@ Notes:
This can happen for example if only one (the other) iga is used.
Writing to these files allows adjusting the output devices during
runtime. One can add new devices, remove existing ones or switch
between igas. Essentially you can write a ',' seperated list of device
between igas. Essentially you can write a ',' separated list of device
names (or a single one) in the same format as the output to those
files. You can add a '+' or '-' as a prefix allowing simple addition
and removal of devices. So a prefix '+' adds the devices from your list

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

@ -387,26 +387,6 @@ Who: Tejun Heo <tj@kernel.org>
----------------------------
What: Support for lcd_switch and display_get in asus-laptop driver
When: March 2010
Why: These two features use non-standard interfaces. There are the
only features that really need multiple path to guess what's
the right method name on a specific laptop.
Removing them will allow to remove a lot of code an significantly
clean the drivers.
This will affect the backlight code which won't be able to know
if the backlight is on or off. The platform display file will also be
write only (like the one in eeepc-laptop).
This should'nt affect a lot of user because they usually know
when their display is on or off.
Who: Corentin Chary <corentin.chary@gmail.com>
----------------------------
What: sysfs-class-rfkill state file
When: Feb 2014
Files: net/rfkill/core.c

2
Documentation/filesystems/autofs4-mount-control.txt
View File

@ -309,7 +309,7 @@ ioctlfd field set to the descriptor obtained from the open call.
AUTOFS_DEV_IOCTL_TIMEOUT_CMD
----------------------------
Set the expire timeout for mounts withing an autofs mount point.
Set the expire timeout for mounts within an autofs mount point.
The call requires an initialized struct autofs_dev_ioctl with the
ioctlfd field set to the descriptor obtained from the open call.

18
Documentation/filesystems/caching/netfs-api.txt
View File

@ -95,7 +95,7 @@ restraints as possible on how an index is structured and where it is placed in
the tree. The netfs can even mix indices and data files at the same level, but
it's not recommended.
Each index entry consists of a key of indeterminate length plus some auxilliary
Each index entry consists of a key of indeterminate length plus some auxiliary
data, also of indeterminate length.
There are some limits on indices:
@ -203,23 +203,23 @@ This has the following fields:
If the function is absent, a file size of 0 is assumed.
(6) A function to retrieve auxilliary data from the netfs [optional].
(6) A function to retrieve auxiliary data from the netfs [optional].
This function will be called with the netfs data that was passed to the
cookie acquisition function and the maximum length of auxilliary data that
it may provide. It should write the auxilliary data into the given buffer
cookie acquisition function and the maximum length of auxiliary data that
it may provide. It should write the auxiliary data into the given buffer
and return the quantity it wrote.
If this function is absent, the auxilliary data length will be set to 0.
If this function is absent, the auxiliary data length will be set to 0.
The length of the auxilliary data buffer may be dependent on the key
The length of the auxiliary data buffer may be dependent on the key
length. A netfs mustn't rely on being able to provide more than 400 bytes
for both.
(7) A function to check the auxilliary data [optional].
(7) A function to check the auxiliary data [optional].
This function will be called to check that a match found in the cache for
this object is valid. For instance with AFS it could check the auxilliary
this object is valid. For instance with AFS it could check the auxiliary
data against the data version number returned by the server to determine
whether the index entry in a cache is still valid.
@ -232,7 +232,7 @@ This has the following fields:
(*) FSCACHE_CHECKAUX_NEEDS_UPDATE - the entry requires update
(*) FSCACHE_CHECKAUX_OBSOLETE - the entry should be deleted
This function can also be used to extract data from the auxilliary data in
This function can also be used to extract data from the auxiliary data in
the cache and copy it into the netfs's structures.
(8) A pair of functions to manage contexts for the completion callback

2
Documentation/filesystems/configfs/configfs.txt
View File

@ -409,7 +409,7 @@ As a consequence of this, default_groups cannot be removed directly via
rmdir(2). They also are not considered when rmdir(2) on the parent
group is checking for children.
[Dependant Subsystems]
[Dependent Subsystems]
Sometimes other drivers depend on particular configfs items. For
example, ocfs2 mounts depend on a heartbeat region item. If that

4
Documentation/filesystems/ext4.txt
View File

@ -97,7 +97,7 @@ Note: More extensive information for getting started with ext4 can be
* Inode allocation using large virtual block groups via flex_bg
* delayed allocation
* large block (up to pagesize) support
* efficent new ordered mode in JBD2 and ext4(avoid using buffer head to force
* efficient new ordered mode in JBD2 and ext4(avoid using buffer head to force
the ordering)
[1] Filesystems with a block size of 1k may see a limit imposed by the
@ -106,7 +106,7 @@ directory hash tree having a maximum depth of two.
2.2 Candidate features for future inclusion
* Online defrag (patches available but not well tested)
* reduced mke2fs time via lazy itable initialization in conjuction with
* reduced mke2fs time via lazy itable initialization in conjunction with
the uninit_bg feature (capability to do this is available in e2fsprogs
but a kernel thread to do lazy zeroing of unused inode table blocks
after filesystem is first mounted is required for safety)

2
Documentation/filesystems/gfs2-uevents.txt
View File

@ -62,7 +62,7 @@ be fixed.
The REMOVE uevent is generated at the end of an unsuccessful mount
or at the end of a umount of the filesystem. All REMOVE uevents will
have been preceeded by at least an ADD uevent for the same fileystem,
have been preceded by at least an ADD uevent for the same fileystem,
and unlike the other uevents is generated automatically by the kernel's
kobject subsystem.

2
Documentation/filesystems/gfs2.txt
View File

@ -11,7 +11,7 @@ their I/O so file system consistency is maintained. One of the nifty
features of GFS is perfect consistency -- changes made to the file system
on one machine show up immediately on all other machines in the cluster.
GFS uses interchangable inter-node locking mechanisms, the currently
GFS uses interchangeable inter-node locking mechanisms, the currently
supported mechanisms are:
lock_nolock -- allows gfs to be used as a local file system

2
Documentation/filesystems/ntfs.txt
View File

@ -350,7 +350,7 @@ Note the "Should sync?" parameter "nosync" means that the two mirrors are
already in sync which will be the case on a clean shutdown of Windows. If the
mirrors are not clean, you can specify the "sync" option instead of "nosync"
and the Device-Mapper driver will then copy the entirety of the "Source Device"
to the "Target Device" or if you specified multipled target devices to all of
to the "Target Device" or if you specified multiple target devices to all of
them.
Once you have your table, save it in a file somewhere (e.g. /etc/ntfsvolume1),

2
Documentation/filesystems/ocfs2.txt
View File

@ -80,7 +80,7 @@ user_xattr (*) Enables Extended User Attributes.
nouser_xattr Disables Extended User Attributes.
acl Enables POSIX Access Control Lists support.
noacl (*) Disables POSIX Access Control Lists support.
resv_level=2 (*) Set how agressive allocation reservations will be.
resv_level=2 (*) Set how aggressive allocation reservations will be.
Valid values are between 0 (reservations off) to 8
(maximum space for reservations).
dir_resv_level= (*) By default, directory reservations will scale with file

4
Documentation/filesystems/path-lookup.txt
View File

@ -42,7 +42,7 @@ Path walking overview
A name string specifies a start (root directory, cwd, fd-relative) and a
sequence of elements (directory entry names), which together refer to a path in
the namespace. A path is represented as a (dentry, vfsmount) tuple. The name
elements are sub-strings, seperated by '/'.
elements are sub-strings, separated by '/'.
Name lookups will want to find a particular path that a name string refers to
(usually the final element, or parent of final element). This is done by taking
@ -354,7 +354,7 @@ vfstest 24185492 4945 708725(2.9%) 1076136(4.4%) 0 2651
What this shows is that failed rcu-walk lookups, ie. ones that are restarted
entirely with ref-walk, are quite rare. Even the "vfstest" case which
specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to excercise
specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to exercise
such races is not showing a huge amount of restarts.
Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where

2
Documentation/filesystems/pohmelfs/network_protocol.txt
View File

@ -20,7 +20,7 @@ Commands can be embedded into transaction command (which in turn has own command
so one can extend protocol as needed without breaking backward compatibility as long
as old commands are supported. All string lengths include tail 0 byte.
All commans are transfered over the network in big-endian. CPU endianess is used at the end peers.
All commands are transferred over the network in big-endian. CPU endianess is used at the end peers.
@cmd - command number, which specifies command to be processed. Following
commands are used currently:

6
Documentation/filesystems/proc.txt
View File

@ -543,7 +543,7 @@ just those considered 'most important'. The new vectors are:
their statistics are used by kernel developers and interested users to
determine the occurrence of interrupts of the given type.
The above IRQ vectors are displayed only when relevent. For example,
The above IRQ vectors are displayed only when relevant. For example,
the threshold vector does not exist on x86_64 platforms. Others are
suppressed when the system is a uniprocessor. As of this writing, only
i386 and x86_64 platforms support the new IRQ vector displays.
@ -1202,7 +1202,7 @@ The columns are:
W = can do write operations
U = can do unblank
flags E = it is enabled
C = it is prefered console
C = it is preferred console
B = it is primary boot console
p = it is used for printk buffer
b = it is not a TTY but a Braille device
@ -1331,7 +1331,7 @@ NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see
Documentation/feature-removal-schedule.txt.
Caveat: when a parent task is selected, the oom killer will sacrifice any first
generation children with seperate address spaces instead, if possible. This
generation children with separate address spaces instead, if possible. This
avoids servers and important system daemons from being killed and loses the
minimal amount of work.

2
Documentation/filesystems/squashfs.txt
View File

@ -219,7 +219,7 @@ or if it is stored out of line (in which case the value field stores a
reference to where the actual value is stored). This allows large values
to be stored out of line improving scanning and lookup performance and it
also allows values to be de-duplicated, the value being stored once, and
all other occurences holding an out of line reference to that value.
all other occurrences holding an out of line reference to that value.
The xattr lists are packed into compressed 8K metadata blocks.
To reduce overhead in inodes, rather than storing the on-disk

2
Documentation/filesystems/sysfs.txt
View File

@ -62,7 +62,7 @@ values of the same type.
Mixing types, expressing multiple lines of data, and doing fancy
formatting of data is heavily frowned upon. Doing these things may get
you publically humiliated and your code rewritten without notice.
you publicly humiliated and your code rewritten without notice.
An attribute definition is simply:

2
Documentation/filesystems/vfs.txt
View File

@ -97,7 +97,7 @@ functions:
The passed struct file_system_type describes your filesystem. When a
request is made to mount a filesystem onto a directory in your namespace,
the VFS will call the appropriate mount() method for the specific
filesystem. New vfsmount refering to the tree returned by ->mount()
filesystem. New vfsmount referring to the tree returned by ->mount()
will be attached to the mountpoint, so that when pathname resolution
reaches the mountpoint it will jump into the root of that vfsmount.

8
Documentation/filesystems/xfs-delayed-logging-design.txt
View File

@ -42,7 +42,7 @@ the aggregation of all the previous changes currently held only in the log.
This relogging technique also allows objects to be moved forward in the log so
that an object being relogged does not prevent the tail of the log from ever
moving forward. This can be seen in the table above by the changing
(increasing) LSN of each subsquent transaction - the LSN is effectively a
(increasing) LSN of each subsequent transaction - the LSN is effectively a
direct encoding of the location in the log of the transaction.
This relogging is also used to implement long-running, multiple-commit
@ -338,7 +338,7 @@ the same time another transaction modifies the item and inserts the log item
into the new CIL, then checkpoint transaction commit code cannot use log items
to store the list of log vectors that need to be written into the transaction.
Hence log vectors need to be able to be chained together to allow them to be
detatched from the log items. That is, when the CIL is flushed the memory
detached from the log items. That is, when the CIL is flushed the memory
buffer and log vector attached to each log item needs to be attached to the
checkpoint context so that the log item can be released. In diagrammatic form,
the CIL would look like this before the flush:
@ -577,7 +577,7 @@ only becomes unpinned when all the transactions complete and there are no
pending transactions. Thus the pinning and unpinning of a log item is symmetric
as there is a 1:1 relationship with transaction commit and log item completion.
For delayed logging, however, we have an assymetric transaction commit to
For delayed logging, however, we have an asymmetric transaction commit to
completion relationship. Every time an object is relogged in the CIL it goes
through the commit process without a corresponding completion being registered.
That is, we now have a many-to-one relationship between transaction commit and
@ -780,7 +780,7 @@ With delayed logging, there are new steps inserted into the life cycle:
From this, it can be seen that the only life cycle differences between the two
logging methods are in the middle of the life cycle - they still have the same
beginning and end and execution constraints. The only differences are in the
commiting of the log items to the log itself and the completion processing.
committing of the log items to the log itself and the completion processing.
Hence delayed logging should not introduce any constraints on log item
behaviour, allocation or freeing that don't already exist.

2
Documentation/hwmon/abituguru
View File

@ -78,7 +78,7 @@ motherboards (most modern Abit motherboards).
The first and second revision of the uGuru chip in reality is a Winbond
W83L950D in disguise (despite Abit claiming it is "a new microprocessor
designed by the ABIT Engineers"). Unfortunatly this doesn't help since the
designed by the ABIT Engineers"). Unfortunately this doesn't help since the
W83L950D is a generic microcontroller with a custom Abit application running
on it.

8
Documentation/hwmon/abituguru-datasheet
View File

@ -5,9 +5,9 @@ First of all, what I know about uGuru is no fact based on any help, hints or
datasheet from Abit. The data I have got on uGuru have I assembled through
my weak knowledge in "backwards engineering".
And just for the record, you may have noticed uGuru isn't a chip developed by
Abit, as they claim it to be. It's realy just an microprocessor (uC) created by
Abit, as they claim it to be. It's really just an microprocessor (uC) created by
Winbond (W83L950D). And no, reading the manual for this specific uC or
mailing Windbond for help won't give any usefull data about uGuru, as it is
mailing Windbond for help won't give any useful data about uGuru, as it is
the program inside the uC that is responding to calls.
Olle Sandberg <ollebull@gmail.com>, 2005-05-25
@ -41,7 +41,7 @@ later on attached again data-port will hold 0x08, more about this later.
After wider testing of the Linux kernel driver some variants of the uGuru have
turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also
have to test CMD for two different values. On these uGuru's DATA will initally
have to test CMD for two different values. On these uGuru's DATA will initially
hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read
first!
@ -308,5 +308,5 @@ the voltage / clock programming out, I tried reading and only reading banks
resulted in a _permanent_ reprogramming of the voltages, luckily I had the
sensors part configured so that it would shutdown my system on any out of spec
voltages which proprably safed my computer (after a reboot I managed to
immediatly enter the bios and reload the defaults). This probably means that
immediately enter the bios and reload the defaults). This probably means that
the read/write cycle for the non sensor part is different from the sensor part.

2
Documentation/hwmon/abituguru3
View File

@ -47,7 +47,7 @@ This driver supports the hardware monitoring features of the third revision of
the Abit uGuru chip, found on recent Abit uGuru featuring motherboards.
The 3rd revision of the uGuru chip in reality is a Winbond W83L951G.
Unfortunatly this doesn't help since the W83L951G is a generic microcontroller
Unfortunately this doesn't help since the W83L951G is a generic microcontroller
with a custom Abit application running on it.
Despite Abit not releasing any information regarding the uGuru revision 3,

36
Documentation/hwmon/adm1021
View File

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

29
Documentation/hwmon/lm90
View File

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

62
Documentation/hwmon/max16064 Normal file
View File

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

79
Documentation/hwmon/max34440 Normal file
View File

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

69
Documentation/hwmon/max8688 Normal file
View File

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

40
Documentation/hwmon/pmbus
View File

@ -13,26 +13,6 @@ Supported chips:
Prefix: 'ltc2978'
Addresses scanned: -
Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
* Maxim MAX16064
Quad Power-Supply Controller
Prefix: 'max16064'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
* Maxim MAX34440
PMBus 6-Channel Power-Supply Manager
Prefixes: 'max34440'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34440.pdf
* Maxim MAX34441
PMBus 5-Channel Power-Supply Manager and Intelligent Fan Controller
Prefixes: 'max34441'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
* Maxim MAX8688
Digital Power-Supply Controller/Monitor
Prefix: 'max8688'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
* Generic PMBus devices
Prefix: 'pmbus'
Addresses scanned: -
@ -150,11 +130,11 @@ The following attributes are supported. Limits are read-write; all other
attributes are read-only.
inX_input Measured voltage. From READ_VIN or READ_VOUT register.
inX_min Minumum Voltage.
inX_min Minimum Voltage.
From VIN_UV_WARN_LIMIT or VOUT_UV_WARN_LIMIT register.
inX_max Maximum voltage.
From VIN_OV_WARN_LIMIT or VOUT_OV_WARN_LIMIT register.
inX_lcrit Critical minumum Voltage.
inX_lcrit Critical minimum Voltage.
From VIN_UV_FAULT_LIMIT or VOUT_UV_FAULT_LIMIT register.
inX_crit Critical maximum voltage.
From VIN_OV_FAULT_LIMIT or VOUT_OV_FAULT_LIMIT register.
@ -169,17 +149,19 @@ inX_label "vin", "vcap", or "voutY"
currX_input Measured current. From READ_IIN or READ_IOUT register.
currX_max Maximum current.
From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT register.
currX_lcrit Critical minumum output current.
currX_lcrit Critical minimum output current.
From IOUT_UC_FAULT_LIMIT register.
currX_crit Critical maximum current.
From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register.
currX_alarm Current high alarm.
From IIN_OC_WARNING or IOUT_OC_WARNING status.
currX_max_alarm Current high alarm.
From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT status.
currX_lcrit_alarm Output current critical low alarm.
From IOUT_UC_FAULT status.
currX_crit_alarm Current critical high alarm.
From IIN_OC_FAULT or IOUT_OC_FAULT status.
currX_label "iin" or "vinY"
currX_label "iin" or "ioutY"
powerX_input Measured power. From READ_PIN or READ_POUT register.
powerX_cap Output power cap. From POUT_MAX register.
@ -193,13 +175,13 @@ powerX_crit_alarm Output power critical high alarm.
From POUT_OP_FAULT status.
powerX_label "pin" or "poutY"
tempX_input Measured tempererature.
tempX_input Measured temperature.
From READ_TEMPERATURE_X register.
tempX_min Mimimum tempererature. From UT_WARN_LIMIT register.
tempX_max Maximum tempererature. From OT_WARN_LIMIT register.
tempX_lcrit Critical low tempererature.
tempX_min Mimimum temperature. From UT_WARN_LIMIT register.
tempX_max Maximum temperature. From OT_WARN_LIMIT register.
tempX_lcrit Critical low temperature.
From UT_FAULT_LIMIT register.
tempX_crit Critical high tempererature.
tempX_crit Critical high temperature.
From OT_FAULT_LIMIT register.
tempX_min_alarm Chip temperature low alarm. Set by comparing
READ_TEMPERATURE_X with UT_WARN_LIMIT if

8
Documentation/hwmon/smm665
View File

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

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

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

2
Documentation/hwmon/sysfs-interface
View File

@ -579,7 +579,7 @@ channel should not be trusted.
fan[1-*]_fault
temp[1-*]_fault
Input fault condition
0: no fault occured
0: no fault occurred
1: fault condition
RO

2
Documentation/hwmon/w83781d
View File

@ -403,7 +403,7 @@ found out the following values do work as a form of coarse pwm:
0x80 - seems to turn fans off after some time(1-2 minutes)... might be
some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an
old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attemp at Qfan
old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attempt at Qfan
that was dropped at the BIOS)
0x81 - off
0x82 - slightly "on-ner" than off, but my fans do not get to move. I can

2
Documentation/hwmon/w83791d
View File

@ -93,7 +93,7 @@ The sysfs interface to the beep bitmask has migrated from the original legacy
method of a single sysfs beep_mask file to a newer method using multiple
*_beep files as described in .../Documentation/hwmon/sysfs-interface.
A similar change has occured for the bitmap corresponding to the alarms. The
A similar change has occurred for the bitmap corresponding to the alarms. The
original legacy method used a single sysfs alarms file containing a bitmap
of triggered alarms. The newer method uses multiple sysfs *_alarm files
(again following the pattern described in sysfs-interface).

2
Documentation/i2c/busses/i2c-parport-light
View File

@ -4,7 +4,7 @@ Author: Jean Delvare <khali@linux-fr.org>
This driver is a light version of i2c-parport. It doesn't depend
on the parport driver, and uses direct I/O access instead. This might be
prefered on embedded systems where wasting memory for the clean but heavy
preferred on embedded systems where wasting memory for the clean but heavy
parport handling is not an option. The drawback is a reduced portability
and the impossibility to daisy-chain other parallel port devices.

2
Documentation/i2c/busses/i2c-sis96x
View File

@ -35,7 +35,7 @@ or perhaps this...
(kernel versions later than 2.4.18 may fill in the "Unknown"s)
If you cant see it please look on quirk_sis_96x_smbus
If you can't see it please look on quirk_sis_96x_smbus
(drivers/pci/quirks.c) (also if southbridge detection fails)
I suspect that this driver could be made to work for the following SiS

2
Documentation/i2c/busses/i2c-taos-evm
View File

@ -13,7 +13,7 @@ Currently supported devices are:
* TAOS TSL2550 EVM
For addtional information on TAOS products, please see
For additional information on TAOS products, please see
http://www.taosinc.com/

2
Documentation/i2o/README
View File

@ -53,7 +53,7 @@ Symbios Logic (Now LSI)
BoxHill Corporation
Loan of initial FibreChannel disk array used for development work.
European Comission
European Commission
Funding the work done by the University of Helsinki
SysKonnect

2
Documentation/ia64/aliasing-test.c
View File

@ -177,7 +177,7 @@ static int scan_rom(char *path, char *file)
/*
* It's OK if the ROM is unreadable. Maybe there
* is no ROM, or some other error ocurred. The
* is no ROM, or some other error occurred. The
* important thing is that no MCA happened.
*/
if (rc > 0)

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

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

2
Documentation/input/joystick-parport.txt
View File

@ -272,7 +272,7 @@ if you want to use gamecon.c.
Also, the connection is a bit more complex. You'll need a bunch of diodes,
and one pullup resistor. First, you connect the Directions and the button
the same as for db9, however with the diodes inbetween.
the same as for db9, however with the diodes between.
Diodes
(pin 2) -----|<|----> Up

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

@ -46,7 +46,7 @@ c) Falling edge on channel A, channel B in high state
d) Falling edge on channel B, channel A in low state
Parking position. If the encoder enters this state, a full transition
should have happend, unless it flipped back on half the way. The
should have happened, unless it flipped back on half the way. The
'armed' state tells us about that.
2. Platform requirements

2
Documentation/input/walkera0701.txt
View File

@ -77,7 +77,7 @@ pulse length:
24 bin+oct values + 1 bin value = 24*4+1 bits = 97 bits
(Warning, pulses on ACK ar inverted by transistor, irq is rised up on sync
(Warning, pulses on ACK are inverted by transistor, irq is raised up on sync
to bin change or octal value to bin change).
Binary data representations:

2
Documentation/irqflags-tracing.txt
View File

@ -53,5 +53,5 @@ implementation in an architecture: lockdep will detect that and will
turn itself off. I.e. the lock validator will still be reliable. There
should be no crashes due to irq-tracing bugs. (except if the assembly
changes break other code by modifying conditions or registers that
shouldnt be)
shouldn't be)

2
Documentation/isdn/INTERFACE.CAPI
View File

@ -240,7 +240,7 @@ Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert
messages between their transport encoding described in the CAPI 2.0 standard
and their _cmsg structure representation. Note that capi_cmsg2message() does
not know or check the size of its destination buffer. The caller must make
sure it is big enough to accomodate the resulting CAPI message.
sure it is big enough to accommodate the resulting CAPI message.
5. Lower Layer Interface Functions

8
Documentation/kbuild/kbuild.txt
View File

@ -26,11 +26,11 @@ Additional options to the assembler (for built-in and modules).
AFLAGS_MODULE
--------------------------------------------------
Addtional module specific options to use for $(AS).
Additional module specific options to use for $(AS).
AFLAGS_KERNEL
--------------------------------------------------
Addtional options for $(AS) when used for assembler
Additional options for $(AS) when used for assembler
code for code that is compiled as built-in.
KCFLAGS
@ -39,12 +39,12 @@ Additional options to the C compiler (for built-in and modules).
CFLAGS_KERNEL
--------------------------------------------------
Addtional options for $(CC) when used to compile
Additional options for $(CC) when used to compile
code that is compiled as built-in.
CFLAGS_MODULE
--------------------------------------------------
Addtional module specific options to use for $(CC).
Additional module specific options to use for $(CC).
LDFLAGS_MODULE
--------------------------------------------------

2
Documentation/kernel-parameters.txt
View File

@ -699,7 +699,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
ekgdboc= [X86,KGDB] Allow early kernel console debugging
ekgdboc=kbd
This is desgined to be used in conjunction with
This is designed to be used in conjunction with
the boot argument: earlyprintk=vga
edd= [EDD]

2
Documentation/kvm/mmu.txt
View File

@ -23,7 +23,7 @@ The mmu code attempts to satisfy the following requirements:
and framebuffer-based displays
- footprint: keep the amount of pinned kernel memory low (most memory
should be shrinkable)
- reliablity: avoid multipage or GFP_ATOMIC allocations
- reliability: avoid multipage or GFP_ATOMIC allocations
Acronyms
========

2
Documentation/kvm/ppc-pv.txt
View File

@ -136,7 +136,7 @@ Patched instructions
====================
The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions
respectively on 32 bit systems with an added offset of 4 to accomodate for big
respectively on 32 bit systems with an added offset of 4 to accommodate for big
endianness.
The following is a list of mapping the Linux kernel performs when running as

2
Documentation/kvm/timekeeping.txt
View File

@ -81,7 +81,7 @@ Mode 0: Single Timeout. This is a one-shot software timeout that counts down
when the gate is high (always true for timers 0 and 1). When the count
reaches zero, the output goes high.
Mode 1: Triggered One-shot. The output is intially set high. When the gate
Mode 1: Triggered One-shot. The output is initially set high. When the gate
line is set high, a countdown is initiated (which does not stop if the gate is
lowered), during which the output is set low. When the count reaches zero,
the output goes high.

10
Documentation/md.txt
View File

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

4
Documentation/media-framework.txt
View File

@ -194,7 +194,7 @@ each pad.
Links are represented by a struct media_link instance, defined in
include/media/media-entity.h. Each entity stores all links originating at or
targetting any of its pads in a links array. A given link is thus stored
targeting any of its pads in a links array. A given link is thus stored
twice, once in the source entity and once in the target entity. The array is
pre-allocated and grows dynamically as needed.
@ -348,6 +348,6 @@ a streaming entity. Links that can be modified while streaming must be marked
with the MEDIA_LNK_FL_DYNAMIC flag.
If other operations need to be disallowed on streaming entities (such as
changing entities configuration parameters) drivers can explictly check the
changing entities configuration parameters) drivers can explicitly check the
media_entity stream_count field to find out if an entity is streaming. This
operation must be done with the media_device graph_mutex held.

4
Documentation/mips/AU1xxx_IDE.README
View File

@ -39,13 +39,13 @@ Note: for more information, please refer "AMD Alchemy Au1200/Au1550 IDE
Interface and Linux Device Driver" Application Note.
FILES, CONFIGS AND COMPATABILITY
FILES, CONFIGS AND COMPATIBILITY
--------------------------------
Two files are introduced:
a) 'arch/mips/include/asm/mach-au1x00/au1xxx_ide.h'
containes : struct _auide_hwif
contains : struct _auide_hwif
timing parameters for PIO mode 0/1/2/3/4
timing parameters for MWDMA 0/1/2

2
Documentation/misc-devices/ics932s401
View File

@ -5,7 +5,7 @@ Supported chips:
* IDT ICS932S401
Prefix: 'ics932s401'
Addresses scanned: I2C 0x69
Datasheet: Publically available at the IDT website
Datasheet: Publicly available at the IDT website
Author: Darrick J. Wong

2
Documentation/networking/3c359.txt
View File

@ -45,7 +45,7 @@ debugging messages on, that must be done by modified the source code.
Variable MTU size:
The driver can handle a MTU size upto either 4500 or 18000 depending upon
The driver can handle a MTU size up to either 4500 or 18000 depending upon
ring speed. The driver also changes the size of the receive buffers as part
of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring

2
Documentation/networking/README.ipw2200
View File

@ -256,7 +256,7 @@ You can set the debug level via:
Where $VALUE would be a number in the case of this sysfs entry. The
input to sysfs files does not have to be a number. For example, the
firmware loader used by hotplug utilizes sysfs entries for transfering
firmware loader used by hotplug utilizes sysfs entries for transferring
the firmware image from user space into the driver.
The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries

2
Documentation/networking/bonding.txt
View File

@ -368,7 +368,7 @@ fail_over_mac
gratuitous ARP is lost, communication may be
disrupted.
When this policy is used in conjuction with the mii
When this policy is used in conjunction with the mii
monitor, devices which assert link up prior to being
able to actually transmit and receive are particularly
susceptible to loss of the gratuitous ARP, and an

2
Documentation/networking/caif/Linux-CAIF.txt
View File

@ -136,7 +136,7 @@ The CAIF Protocol implementation contains:
- CFMUX CAIF Mux layer. Handles multiplexing between multiple
physical bearers and multiple channels such as VEI, Datagram, etc.
The MUX keeps track of the existing CAIF Channels and
Physical Instances and selects the apropriate instance based
Physical Instances and selects the appropriate instance based
on Channel-Id and Physical-ID.
- CFFRML CAIF Framing layer. Handles Framing i.e. Frame length

2
Documentation/networking/caif/spi_porting.txt
View File

@ -150,7 +150,7 @@ static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev)
void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev)
{
/* If xfer is true then you should assert the SPI_INT to indicate to
* the master that you are ready to recieve the data from the master
* the master that you are ready to receive the data from the master
* SPI. If xfer is false then you should de-assert SPI_INT to indicate
* that the transfer is done.
*/

2
Documentation/networking/can.txt
View File

@ -240,7 +240,7 @@ solution for a couple of reasons:
the user application using the common CAN filter mechanisms. Inside
this filter definition the (interested) type of errors may be
selected. The reception of error frames is disabled by default.
The format of the CAN error frame is briefly decribed in the Linux
The format of the CAN error frame is briefly described in the Linux
header file "include/linux/can/error.h".
4. How to use Socket CAN

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