/fs/ocfs2/cluster/

diff --git a/.gitignore b/.gitignore
index 51bd99d6a260..cecb3b040cc1 100644
--- a/.gitignore
+++ b/.gitignore

diff --git a/CREDITS b/CREDITS
index 2520ba620ff1..2b88fb37ad50 100644
--- a/CREDITS
+++ b/CREDITS

diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block
index 44f52a4f5903..cbbd3e069945 100644
--- a/Documentation/ABI/testing/sysfs-block
+++ b/Documentation/ABI/testing/sysfs-block

+Contact: Martin K. Petersen <martin.petersen@oracle.com>

+ Storage devices may report a physical block size that is

+ bigger than the logical block size (for instance a drive

+ indicates how many bytes the beginning of the device is

+Contact: Martin K. Petersen <martin.petersen@oracle.com>

+ Storage devices may report a physical block size that is

+ bigger than the logical block size (for instance a drive

+ indicates how many bytes the beginning of the partition

+Contact: Martin K. Petersen <martin.petersen@oracle.com>

+ without resorting to read-modify-write operation. It is

+Contact: Martin K. Petersen <martin.petersen@oracle.com>

+ Storage devices may report a preferred minimum I/O size,

+ without incurring a read-modify-write penalty. For disk

+Contact: Martin K. Petersen <martin.petersen@oracle.com>

+ Storage devices may report an optimal I/O size, which is

+ rarely reported for disk drives. For RAID devices it is

diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss
new file mode 100644
index 000000000000..0a92a7c93a62
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss

+Description: Displays the SCSI INQUIRY page 0 model for logical drive

+Description: Displays the SCSI INQUIRY page 0 revision for logical

+Description: Displays the SCSI INQUIRY page 83 serial number for logical

+Description: Displays the SCSI INQUIRY page 0 vendor for logical drive

+Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/block:cciss!cXdY

diff --git a/Documentation/ABI/testing/sysfs-devices-cache_disable b/Documentation/ABI/testing/sysfs-devices-cache_disable
new file mode 100644
index 000000000000..175bb4f70512
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-cache_disable

+What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X

+Description: These files exist in every cpu's cache index directories.

+ files will cause the specificed cache index to be disabled.

+ Currently, only AMD Family 10h Processors support cache index

+ disable, and only for their L3 caches. See the BIOS and

+ http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116-Public-GH-BKDG_3.20_2-4-09.pdf

diff --git a/Documentation/ABI/testing/sysfs-kernel-slab b/Documentation/ABI/testing/sysfs-kernel-slab
new file mode 100644
index 000000000000..6dcf75e594fb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-slab

+ The /sys/kernel/slab directory contains a snapshot of the

+ internal state of the SLUB allocator for each cache. Certain

+ files may be modified to change the behavior of the cache (and

+ The aliases file is read-only and specifies how many caches

+ The align file is read-only and specifies the cache's object

+ The alloc_calls file is read-only and lists the kernel code

+ locations from which allocations for this cache were performed.

+ The alloc_calls file only contains information if debugging is

+ enabled for that cache (see Documentation/vm/slub.txt).

+ The alloc_fastpath file is read-only and specifies how many

+ The alloc_from_partial file is read-only and specifies how

+ many times a cpu slab has been full and it has been refilled

+ The alloc_refill file is read-only and specifies how many

+ times the per-cpu freelist was empty but there were objects

+ The alloc_slab file is read-only and specifies how many times

+ a new slab had to be allocated from the page allocator.

+ The alloc_slowpath file is read-only and specifies how many

+ objects have been allocated using the slow path because of a

+ The cache_dma file is read-only and specifies whether objects

+ The cpu_slabs file is read-only and displays how many cpu slabs

+ The file cpuslab_flush is read-only and specifies how many

+ times a cache's cpu slabs have been flushed as the result of

+ destroying or shrinking a cache, a cpu going offline, or as

+ the result of forcing an allocation from a certain node.

+ The ctor file is read-only and specifies the cache's object

+ constructor function, which is invoked for each object when a

+ The file deactivate_empty is read-only and specifies how many

+ The file deactivate_full is read-only and specifies how many

+ The file deactivate_remote_frees is read-only and specifies how

+ many times a cpu slab has been deactivated and contained free

+ The file deactivate_to_head is read-only and specifies how

+ many times a partial cpu slab was deactivated and added to the

+ The file deactivate_to_tail is read-only and specifies how

+ many times a partial cpu slab was deactivated and added to the

+ The destroy_by_rcu file is read-only and specifies whether

+ The file free_add_partial is read-only and specifies how many

+ times an object has been freed in a full slab so that it had to

+ The free_calls file is read-only and lists the locations of

+ The free_fastpath file is read-only and specifies how many

+ objects have been freed using the fast path because it was an

+ The free_frozen file is read-only and specifies how many

+ objects have been freed to a frozen slab (i.e. a remote cpu

+ The file free_remove_partial is read-only and specifies how

+ many times an object has been freed to a now-empty slab so

+ that it had to be removed from its node's partial list.

+ The free_slab file is read-only and specifies how many times an

+ The free_slowpath file is read-only and specifies how many

+ objects have been freed using the slow path (i.e. to a full or

+ The hwcache_align file is read-only and specifies whether

+ The min_partial file specifies how many empty slabs shall

+ remain on a node's partial list to avoid the overhead of

+ allocating new slabs. Such slabs may be reclaimed by utilizing

+ The object_size file is read-only and specifies the cache's

+ The objects file is read-only and displays how many objects are

+ The objects_partial file is read-only and displays how many

+ objects are on partial slabs and from which nodes they are

+ The file objs_per_slab is read-only and specifies how many

+ objects may be allocated from a single slab of the order

+ The order file specifies the page order at which new slabs are

+ allocated. It is writable and can be changed to increase the

+ number of objects per slab. If a slab cannot be allocated

+ because of fragmentation, SLUB will retry with the minimum order

+ The file order_fallback is read-only and specifies how many

+ times an allocation of a new slab has not been possible at the

+ cache's order and instead fallen back to its minimum possible

+ The partial file is read-only and displays how long many

+ partial slabs there are and how long each node's list is.

+ The poison file specifies whether objects should be poisoned

+ The reclaim_account file specifies whether the cache's objects

+ The red_zone file specifies whether the cache's objects are red

+ The file remote_node_defrag_ratio specifies the percentage of

+ times SLUB will attempt to refill the cpu slab with a partial

+ slab from a remote node as opposed to allocating a new slab on

+ the local node. This reduces the amount of wasted memory over

+ The sanity_checks file specifies whether expensive checks

+ should be performed on free and, at minimum, enables double free

+ checks. Caches that enable sanity_checks cannot be merged with

+ The shrink file is written when memory should be reclaimed from

+ a cache. Empty partial slabs are freed and the partial list is

+ sorted so the slabs with the fewest available objects are used

+ The slab_size file is read-only and specifies the object size

+ with metadata (debugging information and alignment) in bytes.

+ The slabs file is read-only and displays how long many slabs

+ there are (both cpu and partial) and from which nodes they are

+ The total_objects file is read-only and displays how many total

+ objects a cache has and from which nodes they are from.

+ The trace file specifies whether object allocations and frees

+ Writing to the validate file causes SLUB to traverse all of its

diff --git a/Documentation/Changes b/Documentation/Changes
index b95082be4d5e..664392481c84 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes

@@ -29,7 +29,7 @@ hardware, for example, you probably needn't concern yourself with

-You will need Gnu make 3.79.1 or later to build the kernel.

+You will need Gnu make 3.80 or later to build the kernel.

@@ -276,6 +277,16 @@ before running exportfs or mountd. It is recommended that all NFS

services be protected from the internet-at-large by a firewall where

+In Linux 2.6.31+ the i386 kernel needs to run the mcelog utility

+as a regular cronjob similar to the x86-64 kernel to process and log

+machine check events when CONFIG_X86_NEW_MCE is enabled. Machine check

+events are errors reported by the CPU. Processing them is strongly encouraged.

+All x86-64 kernels since 2.6.4 require the mcelog utility to

+o <ftp://ftp.kernel.org/pub/linux/utils/cpu/mce/mcelog/>

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 72968cd5eaf3..8bb37237ebd2 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle

@@ -698,8 +698,8 @@ very often is not. Abundant use of the inline keyword leads to a much bigger

kernel, which in turn slows the system as a whole down, due to a bigger

icache footprint for the CPU and simply because there is less memory

available for the pagecache. Just think about it; a pagecache miss causes a

-disk seek, which easily takes 5 miliseconds. There are a LOT of cpu cycles

+disk seek, which easily takes 5 milliseconds. There are a LOT of cpu cycles

A reasonable rule of thumb is to not put inline at functions that have more

than 3 lines of code in them. An exception to this rule are the cases where

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index d9aa43d78bcc..5aceb88b3f8b 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt

@@ -676,8 +676,8 @@ this directory the following files can currently be found:

dma-api/all_errors This file contains a numeric value. If this

dma-api/disabled This read-only file contains the character 'Y'

@@ -704,12 +704,24 @@ this directory the following files can currently be found:

If you have this code compiled into your kernel it will be enabled by default.

If you want to boot without the bookkeeping anyway you can provide

'dma_debug=off' as a boot parameter. This will disable DMA-API debugging.

Notice that you can not enable it again at runtime. You have to reboot to do

+If you want to see debug messages only for a special device driver you can

+specify the dma_debug_driver=<drivername> parameter. This will enable the

+driver filter at boot time. The debug code will only print errors for that

+driver afterwards. This filter can be disabled or changed later using debugfs.

When the code disables itself at runtime this is most likely because it ran

out of dma_debug_entries. These entries are preallocated at boot. The number

of preallocated entries is defined per architecture. If it is too low for you

diff --git a/Documentation/DocBook/debugobjects.tmpl b/Documentation/DocBook/debugobjects.tmpl
index 7f5f218015fe..08ff908aa7a2 100644
--- a/Documentation/DocBook/debugobjects.tmpl
+++ b/Documentation/DocBook/debugobjects.tmpl

number of errors are printk'ed including a full stack trace.

- The statistics are available via debugfs/debug_objects/stats.

+ The statistics are available via /sys/kernel/debug/debug_objects/stats.

They provide information about the number of warnings and the

number of successful fixups along with information about the

usage of the internal tracking objects and the state of the

diff --git a/Documentation/DocBook/mac80211.tmpl b/Documentation/DocBook/mac80211.tmpl
index fbeaffc1dcc3..e36986663570 100644
--- a/Documentation/DocBook/mac80211.tmpl
+++ b/Documentation/DocBook/mac80211.tmpl

@@ -145,7 +145,6 @@ usage should require reading the full document.

diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt
index 6389dec33459..93cb28d05dcd 100644
--- a/Documentation/RCU/rculist_nulls.txt
+++ b/Documentation/RCU/rculist_nulls.txt

@@ -118,7 +118,7 @@ to another chain) checking the final 'nulls' value if

is not the slot number, then we must restart the lookup at

the beginning. If the object was moved to the same chain,

diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt
index 068848240a8b..02cced183b2d 100644
--- a/Documentation/RCU/trace.txt
+++ b/Documentation/RCU/trace.txt

@@ -192,23 +192,24 @@ rcu/rcuhier (which displays the struct rcu_node hierarchy).

- 0 c=4011 g=4012 pq=1 pqc=4011 qp=0 rpfq=1 rp=3c2a dt=23301/73 dn=2 df=1882 of=0 ri=2126 ql=2 b=10

- 1 c=4011 g=4012 pq=1 pqc=4011 qp=0 rpfq=3 rp=39a6 dt=78073/1 dn=2 df=1402 of=0 ri=1875 ql=46 b=10

- 2 c=4010 g=4010 pq=1 pqc=4010 qp=0 rpfq=-5 rp=1d12 dt=16646/0 dn=2 df=3140 of=0 ri=2080 ql=0 b=10

- 3 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=2b50 dt=21159/1 dn=2 df=2230 of=0 ri=1923 ql=72 b=10

- 4 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=1644 dt=5783/1 dn=2 df=3348 of=0 ri=2805 ql=7 b=10

- 5 c=4012 g=4013 pq=0 pqc=4011 qp=1 rpfq=3 rp=1aac dt=5879/1 dn=2 df=3140 of=0 ri=2066 ql=10 b=10

- 6 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=ed8 dt=5847/1 dn=2 df=3797 of=0 ri=1266 ql=10 b=10

- 7 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=1fa2 dt=6199/1 dn=2 df=2795 of=0 ri=2162 ql=28 b=10

+ 0 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=10951/1 dn=0 df=1101 of=0 ri=36 ql=0 b=10

+ 1 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=16117/1 dn=0 df=1015 of=0 ri=0 ql=0 b=10

+ 2 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1445/1 dn=0 df=1839 of=0 ri=0 ql=0 b=10

+ 3 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=6681/1 dn=0 df=1545 of=0 ri=0 ql=0 b=10

+ 4 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1003/1 dn=0 df=1992 of=0 ri=0 ql=0 b=10

+ 5 c=17829 g=17830 pq=1 pqc=17829 qp=1 dt=3887/1 dn=0 df=3331 of=0 ri=4 ql=2 b=10

+ 6 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=859/1 dn=0 df=3224 of=0 ri=0 ql=0 b=10

+ 7 c=17829 g=17830 pq=0 pqc=17829 qp=1 dt=3761/1 dn=0 df=1818 of=0 ri=0 ql=2 b=10

- 0 c=-268 g=-268 pq=1 pqc=-268 qp=0 rpfq=-145 rp=21d6 dt=23301/73 dn=2 df=0 of=0 ri=0 ql=0 b=10

- 1 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-170 rp=20ce dt=78073/1 dn=2 df=26 of=0 ri=5 ql=0 b=10

- 2 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-83 rp=fbd dt=16646/0 dn=2 df=28 of=0 ri=4 ql=0 b=10

- 3 c=-268 g=-268 pq=1 pqc=-268 qp=0 rpfq=-105 rp=178c dt=21159/1 dn=2 df=28 of=0 ri=2 ql=0 b=10

- 4 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-30 rp=b54 dt=5783/1 dn=2 df=32 of=0 ri=0 ql=0 b=10

- 5 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-29 rp=df5 dt=5879/1 dn=2 df=30 of=0 ri=3 ql=0 b=10

- 6 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-28 rp=788 dt=5847/1 dn=2 df=32 of=0 ri=0 ql=0 b=10

- 7 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-53 rp=1098 dt=6199/1 dn=2 df=30 of=0 ri=3 ql=0 b=10

+ 0 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=10951/1 dn=0 df=0 of=0 ri=0 ql=0 b=10

+ 1 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=16117/1 dn=0 df=13 of=0 ri=0 ql=0 b=10

+ 2 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1445/1 dn=0 df=15 of=0 ri=0 ql=0 b=10

+ 3 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=6681/1 dn=0 df=9 of=0 ri=0 ql=0 b=10

+ 4 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1003/1 dn=0 df=15 of=0 ri=0 ql=0 b=10

+ 5 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3887/1 dn=0 df=15 of=0 ri=0 ql=0 b=10

+ 6 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=859/1 dn=0 df=15 of=0 ri=0 ql=0 b=10

+ 7 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3761/1 dn=0 df=15 of=0 ri=0 ql=0 b=10

The first section lists the rcu_data structures for rcu, the second for

rcu_bh. Each section has one line per CPU, or eight for this 8-CPU system.

@@ -253,12 +254,6 @@ o "pqc" indicates which grace period the last-observed quiescent

o "qp" indicates that RCU still expects a quiescent state from

-o "rpfq" is the number of rcu_pending() calls on this CPU required

-o "rp" is low-order four hex digits of the count of how many times

o "dt" is the current value of the dyntick counter that is incremented

when entering or leaving dynticks idle state, either by the

scheduler or by irq. The number after the "/" is the interrupt

@@ -305,6 +300,9 @@ o "b" is the batch limit for this CPU. If more than this number

of RCU callbacks is ready to invoke, then the remainder will

+There is also an rcu/rcudata.csv file with the same information in

@@ -411,3 +409,63 @@ o Each element of the form "1/1 0:127 ^0" represents one struct

+ 0 np=255892 qsp=53936 cbr=0 cng=14417 gpc=10033 gps=24320 nf=6445 nn=146741

+ 1 np=261224 qsp=54638 cbr=0 cng=25723 gpc=16310 gps=2849 nf=5912 nn=155792

+ 2 np=237496 qsp=49664 cbr=0 cng=2762 gpc=45478 gps=1762 nf=1201 nn=136629

+ 3 np=236249 qsp=48766 cbr=0 cng=286 gpc=48049 gps=1218 nf=207 nn=137723

+ 4 np=221310 qsp=46850 cbr=0 cng=26 gpc=43161 gps=4634 nf=3529 nn=123110

+ 5 np=237332 qsp=48449 cbr=0 cng=54 gpc=47920 gps=3252 nf=201 nn=137456

+ 6 np=219995 qsp=46718 cbr=0 cng=50 gpc=42098 gps=6093 nf=4202 nn=120834

+ 7 np=249893 qsp=49390 cbr=0 cng=72 gpc=38400 gps=17102 nf=41 nn=144888

+ 0 np=146741 qsp=1419 cbr=0 cng=6 gpc=0 gps=0 nf=2 nn=145314

+ 1 np=155792 qsp=12597 cbr=0 cng=0 gpc=4 gps=8 nf=3 nn=143180

+ 2 np=136629 qsp=18680 cbr=0 cng=0 gpc=7 gps=6 nf=0 nn=117936

+ 3 np=137723 qsp=2843 cbr=0 cng=0 gpc=10 gps=7 nf=0 nn=134863

+ 4 np=123110 qsp=12433 cbr=0 cng=0 gpc=4 gps=2 nf=0 nn=110671

+ 5 np=137456 qsp=4210 cbr=0 cng=0 gpc=6 gps=5 nf=0 nn=133235

+ 6 np=120834 qsp=9902 cbr=0 cng=0 gpc=6 gps=3 nf=2 nn=110921

+ 7 np=144888 qsp=26336 cbr=0 cng=0 gpc=8 gps=2 nf=0 nn=118542

+As always, this is once again split into "rcu" and "rcu_bh" portions.

+o "np" is the number of times that __rcu_pending() has been invoked

+o "qsp" is the number of times that the RCU was waiting for a

+o "cbr" is the number of times that this CPU had RCU callbacks

+ that had passed through a grace period, and were thus ready

+o "cng" is the number of times that this CPU needed another

+o "gpc" is the number of times that an old grace period had

+o "gps" is the number of times that a new grace period had started,

+o "nf" is the number of times that this CPU suspected that the

+ current grace period had run for too long, and thus needed to

+ Please note that "forcing" consists of sending resched IPIs

+ to holdout CPUs. If that CPU really still is in an old RCU

+ read-side critical section, then we really do have to wait for it.

+ The assumption behing "forcing" is that the CPU is not still in

+ an old RCU read-side critical section, but has not yet responded

+o "nn" is the number of times that this CPU needed nothing. Alert

+ readers will note that the rcu "nn" number for a given CPU very

+ closely matches the rcu_bh "np" number for that same CPU. This

diff --git a/Documentation/SM501.txt b/Documentation/SM501.txt
index 6fc656035925..561826f82093 100644
--- a/Documentation/SM501.txt
+++ b/Documentation/SM501.txt

The Silicon Motion SM501 multimedia companion chip is a multifunction device

which may provide numerous interfaces including USB host controller USB gadget,

-Asyncronous Serial ports, Audio functions and a dual display video interface.

+asynchronous serial ports, audio functions, and a dual display video interface.

The device may be connected by PCI or local bus with varying functions enabled.

diff --git a/Documentation/Smack.txt b/Documentation/Smack.txt
index 629c92e99783..34614b4c708e 100644
--- a/Documentation/Smack.txt
+++ b/Documentation/Smack.txt

@@ -184,8 +184,9 @@ length. Single character labels using special characters, that being anything

other than a letter or digit, are reserved for use by the Smack development

team. Smack labels are unstructured, case sensitive, and the only operation

ever performed on them is comparison for equality. Smack labels cannot

-contain unprintable characters or the "/" (slash) character. Smack labels

-cannot begin with a '-', which is reserved for special options.

+contain unprintable characters, the "/" (slash), the "\" (backslash), the "'"

+Smack labels cannot begin with a '-', which is reserved for special options.

+If you want Smack auditing of security events, you need to set CONFIG_AUDIT

+By default, all denied events will be audited. You can change this behavior by

+Events are logged as 'key=value' pairs, for each event you at least will get

+the subjet, the object, the rights requested, the action, the kernel function

+that triggered the event, plus other pairs depending on the type of event

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index f309d3c6221c..5c555a8b39e5 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches

@@ -91,6 +91,10 @@ Be as specific as possible. The WORST descriptions possible include

things like "update driver X", "bug fix for driver X", or "this patch

+The maintainer will thank you if you write your patch description in a

+form which can be easily pulled into Linux's source code management

If your description starts to get long, that's a sign that you probably

@@ -183,8 +187,9 @@ Even if the maintainer did not respond in step #4, make sure to ALWAYS

For small patches you may want to CC the Trivial Patch Monkey

-trivial@kernel.org managed by Jesper Juhl; which collects "trivial"

-patches. Trivial patches must qualify for one of the following rules:

+trivial@kernel.org which collects "trivial" patches. Have a look

+Trivial patches must qualify for one of the following rules:

@@ -196,7 +201,6 @@ patches. Trivial patches must qualify for one of the following rules:

Any fix by the author/maintainer of the file (ie. patch monkey

-URL: <http://www.kernel.org/pub/linux/kernel/people/juhl/trivial/>

@@ -405,7 +409,14 @@ person it names. This tag documents that potentially interested parties

+If this patch fixes a problem reported by somebody else, consider adding a

+Reported-by: tag to credit the reporter for their contribution. Please

+note that this tag should not be added without the reporter's permission,

+especially if the problem was not reported in a public forum. That said,

+if we diligently credit our bug reporters, they will, hopefully, be

A Tested-by: tag indicates that the patch has been successfully tested (in

some environment) by the person named. This tag informs maintainers that

@@ -444,7 +455,7 @@ offer a Reviewed-by tag for a patch. This tag serves to give credit to

reviewers and to inform maintainers of the degree of review which has been

done on the patch. Reviewed-by: tags, when supplied by reviewers known to

understand the subject area and to perform thorough reviews, will normally

-increase the liklihood of your patch getting into the kernel.

+increase the likelihood of your patch getting into the kernel.

@@ -485,12 +496,33 @@ phrase" should not be a filename. Do not use the same "summary

phrase" for every patch in a whole patch series (where a "patch

series" is an ordered sequence of multiple, related patches).

-Bear in mind that the "summary phrase" of your email becomes

-a globally-unique identifier for that patch. It propagates

-all the way into the git changelog. The "summary phrase" may

-later be used in developer discussions which refer to the patch.

-People will want to google for the "summary phrase" to read

+Bear in mind that the "summary phrase" of your email becomes a

+globally-unique identifier for that patch. It propagates all the way

+into the git changelog. The "summary phrase" may later be used in

+developer discussions which refer to the patch. People will want to

+google for the "summary phrase" to read discussion regarding that

+patch. It will also be the only thing that people may quickly see

+when, two or three months later, they are going through perhaps

+thousands of patches using tools such as "gitk" or "git log

+For these reasons, the "summary" must be no more than 70-75

+characters, and it must describe both what the patch changes, as well

+as why the patch might be necessary. It is challenging to be both

+succinct and descriptive, but that is what a well-written summary

+The "summary phrase" may be prefixed by tags enclosed in square

+brackets: "Subject: [PATCH tag] <summary phrase>". The tags are not

+considered part of the summary phrase, but describe how the patch

+should be treated. Common tags might include a version descriptor if

+the multiple versions of the patch have been sent out in response to

+comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for

+comments. If there are four patches in a patch series the individual

+patches may be numbered like this: 1/4, 2/4, 3/4, 4/4. This assures

+that developers understand the order in which the patches should be

+applied and that they have reviewed or applied all of the patches in

The explanation body will be committed to the permanent source

changelog, so should make sense to a competent reader who has long

since forgotten the immediate details of the discussion that might

+have led to this patch. Including symptoms of the failure which the

+patch addresses (kernel log messages, oops messages, etc.) is

+especially useful for people who might be searching the commit logs

+looking for the applicable patch. If a patch fixes a compile failure,

+it may not be necessary to include _all_ of the compile failures; just

+enough that it is likely that someone searching for the patch can find

+it. As in the "summary phrase", it is important to be both succinct as

The "---" marker line serves the essential purpose of marking for patch

One good use for the additional comments after the "---" marker is for

-a diffstat, to show what files have changed, and the number of inserted

-and deleted lines per file. A diffstat is especially useful on bigger

-patches. Other comments relevant only to the moment or the maintainer,

-not suitable for the permanent changelog, should also go here.

-Use diffstat options "-p 1 -w 70" so that filenames are listed from the

-top of the kernel source tree and don't use too much horizontal space

-(easily fit in 80 columns, maybe with some indentation).

+a diffstat, to show what files have changed, and the number of

+inserted and deleted lines per file. A diffstat is especially useful

+on bigger patches. Other comments relevant only to the moment or the

+maintainer, not suitable for the permanent changelog, should also go

+here. A good example of such comments might be "patch changelogs"

+which describe what has changed between the v1 and v2 version of the

+If you are going to include a diffstat after the "---" marker, please

+use diffstat options "-p 1 -w 70" so that filenames are listed from

+the top of the kernel source tree and don't use too much horizontal

+space (easily fit in 80 columns, maybe with some indentation).

See more details on the proper patch format in the following

diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c
index 7ea231172c85..aa73e72fd793 100644
--- a/Documentation/accounting/getdelays.c
+++ b/Documentation/accounting/getdelays.c

@@ -246,7 +246,8 @@ void print_ioacct(struct taskstats *t)

diff --git a/Documentation/arm/Samsung-S3C24XX/GPIO.txt b/Documentation/arm/Samsung-S3C24XX/GPIO.txt
index ea7ccfc4b274..948c8718d967 100644
--- a/Documentation/arm/Samsung-S3C24XX/GPIO.txt
+++ b/Documentation/arm/Samsung-S3C24XX/GPIO.txt

Each pin has an unique number associated with it in regs-gpio.h,

- eg S3C2410_GPA0 or S3C2410_GPF1. These defines are used to tell

+ eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell

- s3c2410_gpio_cfgpin(S3C2410_GPE8, S3C2410_GPE8_SDDAT1);

+ s3c2410_gpio_cfgpin(S3C2410_GPA(0), S3C2410_GPA0_ADDR0);

+ s3c2410_gpio_cfgpin(S3C2410_GPE(8), S3C2410_GPE8_SDDAT1);

- which would turn GPA0 into the lowest Address line A0, and set

- GPE8 to be connected to the SDIO/MMC controller's SDDAT1 line.

+ which would turn GPA(0) into the lowest Address line A0, and set

+ GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.

diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index 4ef245010457..396bec3b74ed 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt

@@ -229,10 +229,10 @@ kernel. It is the use of atomic counters to implement reference

counting, and it works such that once the counter falls to zero it can

be guaranteed that no other entity can be accessing the object:

+static void obj_list_add(struct obj *obj, struct list_head *head)

diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index 6fab97ea7e6b..8d2158a1c6aa 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt

@@ -186,7 +186,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address

do not have a corresponding kernel virtual address space mapping) and

-Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion

+Note: Please refer to Documentation/DMA-mapping.txt for a discussion

on PCI high mem DMA aspects and mapping of scatter gather lists, and support

diff --git a/Documentation/block/deadline-iosched.txt b/Documentation/block/deadline-iosched.txt
index 72576769e0f4..2d82c80322cb 100644
--- a/Documentation/block/deadline-iosched.txt
+++ b/Documentation/block/deadline-iosched.txt

-Sometimes it happens that a request enters the io scheduler that is contigious

+Sometimes it happens that a request enters the io scheduler that is contiguous

with a request that is already on the queue. Either it fits in the back of that

request, or it fits at the front. That is called either a back merge candidate

or a front merge candidate. Due to the way files are typically laid out,

diff --git a/Documentation/braille-console.txt b/Documentation/braille-console.txt
index 000b0fbdc105..d0d042c2fd5e 100644
--- a/Documentation/braille-console.txt
+++ b/Documentation/braille-console.txt

For simplicity, only one braille console can be enabled, other uses of

console=brl,... will be discarded. Also note that it does not interfere with

-the console selection mecanism described in serial-console.txt

+the console selection mechanism described in serial-console.txt

diff --git a/Documentation/cdrom/packet-writing.txt b/Documentation/cdrom/packet-writing.txt
index cf1f8126991c..1c407778c8b2 100644
--- a/Documentation/cdrom/packet-writing.txt
+++ b/Documentation/cdrom/packet-writing.txt

For a description of the debugfs interface look into the file:

diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt
index c11b931f8f98..15174985ad08 100644
--- a/Documentation/dell_rbu.txt
+++ b/Documentation/dell_rbu.txt

@@ -76,9 +76,9 @@ Do the steps below to download the BIOS image.

The /sys/class/firmware/dell_rbu/ entries will remain till the following is

Until this step is completed the driver cannot be unloaded.

-Also echoing either mono ,packet or init in to image_type will free up the

+Also echoing either mono, packet or init in to image_type will free up the

If a user by accident executes steps 1 and 3 above without executing step 2;

diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting
index dd48132a74dd..f622c1e9f0f9 100644
--- a/Documentation/development-process/5.Posting
+++ b/Documentation/development-process/5.Posting

@@ -119,7 +119,7 @@ which takes quite a bit of time and thought after the "real work" has been

So now you have a perfect series of patches for posting, but the work is

not done quite yet. Each patch needs to be formatted into a message which

@@ -146,8 +146,33 @@ that end, each patch will be composed of the following:

- One or more tag lines, with, at a minimum, one Signed-off-by: line from

the author of the patch. Tags will be described in more detail below.

-The above three items should, normally, be the text used when committing

-the change to a revision control system. They are followed by:

+The items above, together, form the changelog for the patch. Writing good

+changelogs is a crucial but often-neglected art; it's worth spending

+another moment discussing this issue. When writing a changelog, you should

+bear in mind that a number of different people will be reading your words.

+These include subsystem maintainers and reviewers who need to decide

+whether the patch should be included, distributors and other maintainers

+trying to decide whether a patch should be backported to other kernels, bug

+hunters wondering whether the patch is responsible for a problem they are

+chasing, users who want to know how the kernel has changed, and more. A

+good changelog conveys the needed information to all of these people in the

+To that end, the summary line should describe the effects of and motivation

+for the change as well as possible given the one-line constraint. The

+detailed description can then amplify on those topics and provide any

+needed additional information. If the patch fixes a bug, cite the commit

+which introduced the bug if possible. If a problem is associated with

+specific log or compiler output, include that output to help others

+searching for a solution to the same problem. If the change is meant to

+support other changes coming in later patch, say so. If internal APIs are

+changed, detail those changes and how other developers should respond. In

+general, the more you can put yourself into the shoes of everybody who will

+be reading your changelog, the better that changelog (and the kernel as a

+Needless to say, the changelog should be the text used when committing the

+change to a revision control system. It will be followed by:

- The patch itself, in the unified ("-u") patch format. Using the "-p"

option to diff will associate function names with changes, making the

diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt
index a7cbfff40d07..a124f3126b0d 100644
--- a/Documentation/driver-model/device.txt
+++ b/Documentation/driver-model/device.txt

@@ -162,3 +162,35 @@ device_remove_file(dev,&dev_attr_power);

The file name will be 'power' with a mode of 0644 (-rw-r--r--).

+Word of warning: While the kernel allows device_create_file() and

+device_remove_file() to be called on a device at any time, userspace has

+strict expectations on when attributes get created. When a new device is

+registered in the kernel, a uevent is generated to notify userspace (like

+udev) that a new device is available. If attributes are added after the

+device is registered, then userspace won't get notified and userspace will

+This is important for device driver that need to publish additional

+attributes for a device at driver probe time. If the device driver simply

+calls device_create_file() on the device structure passed to it, then

+userspace will never be notified of the new attributes. Instead, it should

+probably use class_create() and class->dev_attrs to set up a list of

+desired attributes in the modules_init function, and then in the .probe()

+hook, and then use device_create() to create a new device as a child

+of the probed device. The new device will generate a new uevent and

+For example, if a driver wanted to add the following attributes:

+ mydriver_class = class_create(THIS_MODULE, "my_attrs");

+And assuming 'dev' is the struct device passed into the probe hook, the driver

+ create_device(&mydriver_class, dev, chrdev, &private_data, "my_name");

diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 387b8a720f4a..d79aead9418b 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt

@@ -188,7 +188,7 @@ For example, you can do something like the following.

- devres_release_group(dev, my_midlayer_create_soemthing);

+ devres_release_group(dev, my_midlayer_create_something);

diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index 2f21ecd4c205..a52adfc9a57f 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware

- my $url = "http://technotrend-online.com/download/software/219/$sourcefile";

+ my $url = "http://www.tt-download.com/download/updates/219/$sourcefile";

- my $url = "http://www.lifeview.com.tw/drivers/pci_card/FlyDVB-T/$sourcefile";

+ my $url = "http://www.lifeview.hk/dbimages/document/$sourcefile";

- my $url = "http://www.aver.com/support/Drivers/$sourcefile";

+ my $url = "http://www.avermedia-usa.com/support/Drivers/$sourcefile";

diff --git a/Documentation/edac.txt b/Documentation/edac.txt
index 8eda3fb66416..06f8f46692dc 100644
--- a/Documentation/edac.txt
+++ b/Documentation/edac.txt

The bluesmoke project at sourceforge.net is now utilized as a 'staging area'

for EDAC development, before it is sent upstream to kernel.org

-At the bluesmoke/EDAC project site, is a series of quilt patches against

-recent kernels, stored in a SVN respository. For easier downloading, there

+At the bluesmoke/EDAC project site is a series of quilt patches against

+recent kernels, stored in a SVN repository. For easier downloading, there

============================================================================

@@ -73,9 +73,9 @@ the vendor should tie the parity status bits to 0 if they do not intend

to generate parity. Some vendors do not do this, and thus the parity bit

-In the kernel there is a pci device attribute located in sysfs that is

+In the kernel there is a PCI device attribute located in sysfs that is

checked by the EDAC PCI scanning code. If that attribute is set,

-PCI parity/error scannining is skipped for that device. The attribute

+PCI parity/error scanning is skipped for that device. The attribute

diff --git a/Documentation/fault-injection/fault-injection.txt b/Documentation/fault-injection/fault-injection.txt
index 4bc374a14345..079305640790 100644
--- a/Documentation/fault-injection/fault-injection.txt
+++ b/Documentation/fault-injection/fault-injection.txt

fault-inject-debugfs kernel module provides some debugfs entries for runtime

Note that one-failure-per-hundred is a very high error rate

for some testcases. Consider setting probability=100 and configure

@@ -46,18 +46,18 @@ configuration of fault-injection capabilities.

Note that if you enable this, by setting interval>1, you will

specifies an initial resource "budget", decremented by "size"

@@ -65,17 +65,17 @@ configuration of fault-injection capabilities.

log line per failure; '2' will print a call trace too -- useful

Any positive value limits failures to only processes indicated by

stacktrace walking. Failure is injected only if some caller

@@ -84,26 +84,26 @@ configuration of fault-injection capabilities.

Default required range is [0,ULONG_MAX) (whole of virtual address space).

specifies the maximum stacktrace depth walked during search

default is 'N', setting it to 'Y' won't inject failures into

only into non-sleep allocations (GFP_ATOMIC allocations).

specifies the minimum page allocation order to be injected

@@ -166,13 +166,13 @@ o Inject slab allocation failures into module init/exit code

-cat /sys/module/$module/sections/.text > /debug/$FAILTYPE/require-start

-cat /sys/module/$module/sections/.data > /debug/$FAILTYPE/require-end

+cat /sys/module/$module/sections/.text > /sys/kernel/debug/$FAILTYPE/require-start

+cat /sys/module/$module/sections/.data > /sys/kernel/debug/$FAILTYPE/require-end

-trap "echo 0 > /debug/$FAILTYPE/probability" SIGINT SIGTERM EXIT

+trap "echo 0 > /sys/kernel/debug/$FAILTYPE/probability" SIGINT SIGTERM EXIT

echo "Injecting errors into the module $module... (interrupt to stop)"

diff --git a/Documentation/fb/sh7760fb.txt b/Documentation/fb/sh7760fb.txt
index c87bfe5c630a..b994c3b10549 100644
--- a/Documentation/fb/sh7760fb.txt
+++ b/Documentation/fb/sh7760fb.txt

The SH7760/SH7763 have an integrated LCD Display controller (LCDC) which

supports (in theory) resolutions ranging from 1x1 to 1024x1024,

diff --git a/Documentation/fb/vesafb.txt b/Documentation/fb/vesafb.txt
index ee277dd204b0..950d5a658cb3 100644
--- a/Documentation/fb/vesafb.txt
+++ b/Documentation/fb/vesafb.txt

@@ -95,7 +95,7 @@ There is no way to change the vesafb video mode and/or timings after

booting linux. If you are not happy with the 60 Hz refresh rate, you

- * configure and load the DOS-Tools for your the graphics board (if

+ * configure and load the DOS-Tools for the graphics board (if

* use a native driver (matroxfb/atyfb) instead if vesafb. If none

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index de491a3e2313..7129846a2785 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt

@@ -437,3 +437,20 @@ Why: Superseded by tdfxfb. I2C/DDC support used to live in a separate

+Why: Remove the old legacy 32bit machine check code. This has been

+ superseded by the newer machine check code from the 64bit port,

+ but the old version has been kept around for easier testing. Note this

+ doesn't impact the old P5 and WinChip machine check handlers.

diff --git a/Documentation/filesystems/autofs4-mount-control.txt b/Documentation/filesystems/autofs4-mount-control.txt
index c6341745df37..8f78ded4b648 100644
--- a/Documentation/filesystems/autofs4-mount-control.txt
+++ b/Documentation/filesystems/autofs4-mount-control.txt

@@ -369,7 +369,7 @@ The call requires an initialized struct autofs_dev_ioctl. There are two

possible variations. Both use the path field set to the path of the mount

point to check and the size field adjusted appropriately. One uses the

ioctlfd field to identify a specific mount point to check while the other

-variation uses the path and optionaly arg1 set to an autofs mount type.

+variation uses the path and optionally arg1 set to an autofs mount type.

The call returns 1 if this is a mount point and sets arg1 to the device

number of the mount and field arg2 to the relevant super block magic

number (described below) or 0 if it isn't a mountpoint. In both cases

diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt
index 4db125b3a5c6..2666b1ed5e9e 100644
--- a/Documentation/filesystems/caching/netfs-api.txt
+++ b/Documentation/filesystems/caching/netfs-api.txt

If this function is not supplied or if it returns NULL then the first

- cache in the parent's list will be chosed, or failing that, the first

+ cache in the parent's list will be chosen, or failing that, the first

(4) A function to retrieve an object's key from the netfs [mandatory].

diff --git a/Documentation/filesystems/debugfs.txt b/Documentation/filesystems/debugfs.txt
new file mode 100644
index 000000000000..ed52af60c2d8
--- /dev/null
+++ b/Documentation/filesystems/debugfs.txt

+Debugfs exists as a simple way for kernel developers to make information

+available to user space. Unlike /proc, which is only meant for information

+about a process, or sysfs, which has strict one-value-per-file rules,

+debugfs has no rules at all. Developers can put any information they want

+there. The debugfs filesystem is also intended to not serve as a stable

+ABI to user space; in theory, there are no stability constraints placed on

+files exported there. The real world is not always so simple, though [1];

+even debugfs interfaces are best designed with the idea that they will need

+Note that the debugfs API is exported GPL-only to modules.

+Code using debugfs should include <linux/debugfs.h>. Then, the first order

+of business will be to create at least one directory to hold a set of

+ struct dentry *debugfs_create_dir(const char *name, struct dentry *parent);

+This call, if successful, will make a directory called name underneath the

+indicated parent directory. If parent is NULL, the directory will be

+created in the debugfs root. On success, the return value is a struct

+dentry pointer which can be used to create files in the directory (and to

+clean it up at the end). A NULL return value indicates that something went

+wrong. If ERR_PTR(-ENODEV) is returned, that is an indication that the

+kernel has been built without debugfs support and none of the functions

+The most general way to create a file within a debugfs directory is with:

+ struct dentry *debugfs_create_file(const char *name, mode_t mode,

+Here, name is the name of the file to create, mode describes the access

+permissions the file should have, parent indicates the directory which

+should hold the file, data will be stored in the i_private field of the

+resulting inode structure, and fops is a set of file operations which

+implement the file's behavior. At a minimum, the read() and/or write()

+operations should be provided; others can be included as needed. Again,

+the return value will be a dentry pointer to the created file, NULL for

+error, or ERR_PTR(-ENODEV) if debugfs support is missing.

+In a number of cases, the creation of a set of file operations is not

+actually necessary; the debugfs code provides a number of helper functions

+for simple situations. Files containing a single integer value can be

+ struct dentry *debugfs_create_u8(const char *name, mode_t mode,

+ struct dentry *debugfs_create_u16(const char *name, mode_t mode,

+ struct dentry *debugfs_create_u32(const char *name, mode_t mode,

+ struct dentry *debugfs_create_u64(const char *name, mode_t mode,

+These files support both reading and writing the given value; if a specific

+file should not be written to, simply set the mode bits accordingly. The

+values in these files are in decimal; if hexadecimal is more appropriate,

+ struct dentry *debugfs_create_x8(const char *name, mode_t mode,

+ struct dentry *debugfs_create_x16(const char *name, mode_t mode,

+ struct dentry *debugfs_create_x32(const char *name, mode_t mode,

+These functions are useful as long as the developer knows the size of the

+value to be exported. Some types can have different widths on different

+architectures, though, complicating the situation somewhat. There is a

+ struct dentry *debugfs_create_size_t(const char *name, mode_t mode,

+As might be expected, this function will create a debugfs file to represent

+ struct dentry *debugfs_create_bool(const char *name, mode_t mode,

+A read on the resulting file will yield either Y (for non-zero values) or

+N, followed by a newline. If written to, it will accept either upper- or

+lower-case values, or 1 or 0. Any other input will be silently ignored.

+Finally, a block of arbitrary binary data can be exported with:

+ struct dentry *debugfs_create_blob(const char *name, mode_t mode,

+A read of this file will return the data pointed to by the

+debugfs_blob_wrapper structure. Some drivers use "blobs" as a simple way

+to return several lines of (static) formatted text output. This function

+can be used to export binary information, but there does not appear to be

+any code which does so in the mainline. Note that all files created with

+There are a couple of other directory-oriented helper functions:

+ struct dentry *debugfs_create_symlink(const char *name,

+A call to debugfs_rename() will give a new name to an existing debugfs

+file, possibly in a different directory. The new_name must not exist prior

+to the call; the return value is old_dentry with updated information.

+Symbolic links can be created with debugfs_create_symlink().

+There is one important thing that all debugfs users must take into account:

+there is no automatic cleanup of any directories created in debugfs. If a

+module is unloaded without explicitly removing debugfs entries, the result

+will be a lot of stale pointers and no end of highly antisocial behavior.

+So all debugfs users - at least those which can be built as modules - must

+be prepared to remove all files and directories they create there. A file

+The dentry value can be NULL, in which case nothing will be removed.

+Once upon a time, debugfs users were required to remember the dentry

+pointer for every debugfs file they created so that all files could be

+cleaned up. We live in more civilized times now, though, and debugfs users

+If this function is passed a pointer for the dentry corresponding to the

+top-level directory, the entire hierarchy below that directory will be

diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt
index 97882df04865..608fdba97b72 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt

@@ -294,7 +294,7 @@ max_batch_time=usec Maximum amount of time ext4 should wait for

@@ -328,7 +328,7 @@ noauto_da_alloc replacing existing files via patterns such as

@@ -358,7 +358,7 @@ written to the journal first, and then to its final location.

In the event of a crash, the journal can be replayed, bringing both data and

metadata into a consistent state. This mode is the slowest except when data

needs to be read from and written to disk at the same time where it

-outperforms all others modes. Curently ext4 does not have delayed

+outperforms all others modes. Currently ext4 does not have delayed

allocation support if this data journalling mode is selected.

diff --git a/Documentation/filesystems/fiemap.txt b/Documentation/filesystems/fiemap.txt
index 1e3defcfe50b..606233cd4618 100644
--- a/Documentation/filesystems/fiemap.txt
+++ b/Documentation/filesystems/fiemap.txt

int fiemap_check_flags(struct fiemap_extent_info *fieinfo, u32 fs_flags);

-The struct fieinfo should be passed in as recieved from ioctl_fiemap(). The

+The struct fieinfo should be passed in as received from ioctl_fiemap(). The

set of fiemap flags which the fs understands should be passed via fs_flags. If

fiemap_check_flags finds invalid user flags, it will place the bad values in

fieinfo->fi_flags and return -EBADR. If the file system gets -EBADR, from

diff --git a/Documentation/filesystems/gfs2-glocks.txt b/Documentation/filesystems/gfs2-glocks.txt
index 4dae9a3840bf..0494f78d87e4 100644
--- a/Documentation/filesystems/gfs2-glocks.txt
+++ b/Documentation/filesystems/gfs2-glocks.txt

@@ -60,7 +60,7 @@ go_lock | Called for the first local holder of a lock

go_dump | Called to print content of object for debugfs file, or on

The minimum hold time for each lock is the time after a remote lock

diff --git a/Documentation/filesystems/gfs2.txt b/Documentation/filesystems/gfs2.txt
index 593004b6bbab..5e3ab8f3beff 100644
--- a/Documentation/filesystems/gfs2.txt
+++ b/Documentation/filesystems/gfs2.txt

@@ -11,18 +11,15 @@ 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. Different lock

-modules can plug into GFS and each file system selects the appropriate

+GFS uses interchangable inter-node locking mechanisms, the currently

lock_nolock -- allows gfs to be used as a local file system

lock_dlm -- uses a distributed lock manager (dlm) for inter-node locking

-In addition to interfacing with an external locking manager, a gfs lock

-module is responsible for interacting with external cluster management

-systems. Lock_dlm depends on user space cluster management systems found

+Lock_dlm depends on user space cluster management systems found

To use gfs as a local file system, no external clustering systems are

-GFS2 is not on-disk compatible with previous versions of GFS.

+If you are using Fedora, you need to install the gfs2-utils package

+and, for lock_dlm, you will also need to install the cman package

+GFS2 is not on-disk compatible with previous versions of GFS, but it

gfs2_quota to examine and change quota values in a filesystem

+ gfs2_convert to convert a gfs filesystem to gfs2 in-place

diff --git a/Documentation/filesystems/nfs-rdma.txt b/Documentation/filesystems/nfs-rdma.txt
index 85eaeaddd27c..e386f7e4bcee 100644
--- a/Documentation/filesystems/nfs-rdma.txt
+++ b/Documentation/filesystems/nfs-rdma.txt

In this location, mount.nfs will be invoked automatically for NFS mounts

NOTE: mount.nfs and therefore nfs-utils-1.1.2 or greater is only needed

on the NFS client machine. You do not need this specific version of

diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt
index 55c4300abfcb..01539f410676 100644
--- a/Documentation/filesystems/nilfs2.txt
+++ b/Documentation/filesystems/nilfs2.txt

@@ -39,9 +39,8 @@ Features which NILFS2 does not support yet:

diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index ce84cfc9eae0..ebff3c10a07f 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt

@@ -366,7 +366,7 @@ just those considered 'most important'. The new vectors are:

RES, CAL, TLB -- rescheduling, call and TLB flush interrupts are

sent from one CPU to another per the needs of the OS. Typically,

their statistics are used by kernel developers and interested users to

- determine the occurance of interrupt of the given type.

+ determine the occurrence of interrupts of the given type.

The above IRQ vectors are displayed only when relevent. For example,

the threshold vector does not exist on x86_64 platforms. Others are

@@ -551,7 +551,7 @@ Committed_AS: The amount of memory presently allocated on the system.

-VmallocChunk: largest contigious block of vmalloc area which is free

+VmallocChunk: largest contiguous block of vmalloc area which is free

..............................................................................

@@ -1003,11 +1003,13 @@ CHAPTER 3: PER-PROCESS PARAMETERS

-This file can be used to adjust the score used to select which processes

-should be killed in an out-of-memory situation. Giving it a high score will

-increase the likelihood of this process being killed by the oom-killer. Valid

-values are in the range -16 to +15, plus the special value -17, which disables

+This file can be used to adjust the score used to select which processes should

+be killed in an out-of-memory situation. The oom_adj value is a characteristic

+of the task's mm, so all threads that share an mm with pid will have the same

+oom_adj value. A high value will increase the likelihood of this process being

+killed by the oom-killer. Valid values are in the range -16 to +15 as

+explained below and a special value of -17, which disables oom-killing

The process to be killed in an out-of-memory situation is selected among all others

based on its badness score. This value equals the original memory size of the process

@@ -1021,6 +1023,9 @@ the parent's score if they do not share the same memory. Thus forking servers

are the prime candidates to be killed. Having only one 'hungry' child will make

+/proc/<pid>/oom_adj cannot be changed for kthreads since they are immune from

/proc/<pid>/oom_score shows process' current badness score.

diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt
index 26e4b8bc53ee..85354b32d731 100644
--- a/Documentation/filesystems/sysfs-pci.txt
+++ b/Documentation/filesystems/sysfs-pci.txt

@@ -72,7 +72,7 @@ The 'rom' file is special in that it provides read-only access to the device's

ROM file, if available. It's disabled by default, however, so applications

should write the string "1" to the file to enable it before attempting a read

call, and disable it following the access by writing "0" to the file. Note

-that the device must be enabled for a rom read to return data succesfully.

+that the device must be enabled for a rom read to return data successfully.

In the event a driver is not bound to the device, it can be enabled using the

diff --git a/Documentation/filesystems/tmpfs.txt b/Documentation/filesystems/tmpfs.txt
index 222437efd75a..3015da0c6b2a 100644
--- a/Documentation/filesystems/tmpfs.txt
+++ b/Documentation/filesystems/tmpfs.txt

@@ -133,4 +133,4 @@ RAM/SWAP in 10240 inodes and it is only accessible by root.

diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
index 3a5ddc96901a..b58b84b50fa2 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt

@@ -124,14 +124,19 @@ sys_immutable -- If set, ATTR_SYS attribute on FAT is handled as

flush -- If set, the filesystem will try to flush to disk more

-rodir -- FAT has the ATTR_RO (read-only) attribute. But on Windows,

- the ATTR_RO of the directory will be just ignored actually,

- and is used by only applications as flag. E.g. it's setted

+rodir -- FAT has the ATTR_RO (read-only) attribute. On Windows,

+ and is used only by applications as a flag (e.g. it's set

+ -- specify FAT behavior on critical errors: panic, continue

diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README
index c3480aa66ba8..7eceaff63f5f 100644
--- a/Documentation/firmware_class/README
+++ b/Documentation/firmware_class/README

- request_firmware_nowait() is also provided for convenience in

+ user contexts to request firmware asynchronously, but can't be called

diff --git a/Documentation/futex-requeue-pi.txt b/Documentation/futex-requeue-pi.txt
new file mode 100644
index 000000000000..9dc1ff4fd536
--- /dev/null
+++ b/Documentation/futex-requeue-pi.txt

+Requeueing of tasks from a non-PI futex to a PI futex requires

+special handling in order to ensure the underlying rt_mutex is never

+left without an owner if it has waiters; doing so would break the PI

+boosting logic [see rt-mutex-desgin.txt] For the purposes of

+brevity, this action will be referred to as "requeue_pi" throughout

+this document. Priority inheritance is abbreviated throughout as

+pthread_cond_broadcast() must resort to waking all the tasks waiting

+on a pthread_condvar and letting them try to sort out which task

+gets to run first in classic thundering-herd formation. An ideal

+implementation would wake the highest-priority waiter, and leave the

+rest to the natural wakeup inherent in unlocking the mutex

+Once pthread_cond_broadcast() requeues the tasks, the cond->mutex

+has waiters. Note that pthread_cond_wait() attempts to lock the

+mutex only after it has returned to user space. This will leave the

+underlying rt_mutex with waiters, and no owner, breaking the

+In order to support PI-aware pthread_condvar's, the kernel needs to

+be able to requeue tasks to PI futexes. This support implies that

+upon a successful futex_wait system call, the caller would return to

+user space already holding the PI futex. The glibc implementation

+The actual glibc implementation will likely test for PI and make the

+necessary changes inside the existing calls rather than creating new

+In order to ensure the rt_mutex has an owner if it has waiters, it

+is necessary for both the requeue code, as well as the waiting code,

+to be able to acquire the rt_mutex before returning to user space.

+The requeue code cannot simply wake the waiter and leave it to

+acquire the rt_mutex as it would open a race window between the

+requeue call returning to user space and the waiter waking and

+starting to run. This is especially true in the uncontended case.

+rt_mutex_start_proxy_lock() and rt_mutex_finish_proxy_lock(), which

+allow the requeue code to acquire an uncontended rt_mutex on behalf

+of the waiter and to enqueue the waiter on a contended rt_mutex.

+Two new system calls provide the kernel<->user interface to

+requeue_pi: FUTEX_WAIT_REQUEUE_PI and FUTEX_REQUEUE_CMP_PI.

+FUTEX_WAIT_REQUEUE_PI is called by the waiter (pthread_cond_wait()

+and pthread_cond_timedwait()) to block on the initial futex and wait

+to be requeued to a PI-aware futex. The implementation is the

+result of a high-speed collision between futex_wait() and

+futex_lock_pi(), with some extra logic to check for the additional

+(pthread_cond_broadcast() and pthread_cond_signal()) to requeue and

+possibly wake the waiting tasks. Internally, this system call is

+still handled by futex_requeue (by passing requeue_pi=1). Before

+requeueing, futex_requeue() attempts to acquire the requeue target

+PI futex on behalf of the top waiter. If it can, this waiter is

+woken. futex_requeue() then proceeds to requeue the remaining

+rt_mutex_start_proxy_lock() prior to each requeue to prepare the

+task as a waiter on the underlying rt_mutex. It is possible that

+the lock can be acquired at this stage as well, if so, the next

+FUTEX_REQUEUE_PI accepts nr_wake and nr_requeue as arguments, but

+their sum is all that really matters. futex_requeue() will wake or

+requeue up to nr_wake + nr_requeue tasks. It will wake only as many

+tasks as it can acquire the lock for, which in the majority of cases

+should be 0 as good programming practice dictates that the caller of

+either pthread_cond_broadcast() or pthread_cond_signal() acquire the

+mutex prior to making the call. FUTEX_REQUEUE_PI requires that

+nr_wake=1. nr_requeue should be INT_MAX for broadcast and 0 for

diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index 145c25a170c7..e4b6985044a2 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt

@@ -458,7 +458,7 @@ debugfs interface, since it provides control over GPIO direction and

value instead of just showing a gpio state summary. Plus, it could be

-Given approprate hardware documentation for the system, userspace could

+Given appropriate hardware documentation for the system, userspace could

know for example that GPIO #23 controls the write protect line used to

protect boot loader segments in flash memory. System upgrade procedures

may need to temporarily remove that protection, first importing a GPIO,

diff --git a/Documentation/hwmon/f71882fg b/Documentation/hwmon/f71882fg
index a8321267b5b6..bee4c30bc1e2 100644
--- a/Documentation/hwmon/f71882fg
+++ b/Documentation/hwmon/f71882fg

Addresses scanned: none, address read from Super I/O config space

+ Addresses scanned: none, address read from Super I/O config space

Addresses scanned: none, address read from Super I/O config space

Three different fan control modes are supported; the mode number is written

to the pwm#_enable file. Note that not all modes are supported on all

-chips, and some modes may only be available in RPM / PWM mode on the F8000.

+chips, and some modes may only be available in RPM / PWM mode.

Writing an unsupported mode will result in an invalid parameter error.

You ask for a specific PWM duty cycle / DC voltage or a specific % of

fan#_full_speed by writing to the pwm# file. This mode is only

- available on the F8000 if the fan channel is in RPM mode.

+ available on the F71858FG / F8000 if the fan channel is in RPM mode.

You can define a number of temperature/fan speed trip points, which % the

diff --git a/Documentation/hwmon/ibmaem b/Documentation/hwmon/ibmaem
index e98bdfea3467..1e0d59e000b4 100644
--- a/Documentation/hwmon/ibmaem
+++ b/Documentation/hwmon/ibmaem

This includes the x3350, x3550, x3650, x3655, x3755, x3850 M2,

- x3950 M2, and certain HS2x/LS2x/QS2x blades. The IPMI host interface

+ x3950 M2, and certain HC10/HS2x/LS2x/QS2x blades. The IPMI host interface

driver ("ipmi-si") needs to be loaded for this driver to do anything.

diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index 2f10ce6a879f..dcbd502c8792 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface

@@ -70,6 +70,7 @@ are interpreted as 0! For more on how written strings are interpreted see the

Read/write values may be read-only for some chips, depending on the

@@ -290,6 +296,24 @@ temp[1-*]_label Suggested temperature channel label.

Some chips measure temperature using external thermistors and an ADC, and

report the temperature measurement as a voltage. Converting this voltage

back to a temperature (or the other way around for limits) requires

diff --git a/Documentation/hwmon/tmp401 b/Documentation/hwmon/tmp401
new file mode 100644
index 000000000000..9fc447249212
--- /dev/null
+++ b/Documentation/hwmon/tmp401

+ Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp401.html

+ Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp411.html

+This driver implements support for Texas Instruments TMP401 and

+TMP411 chips. These chips implements one remote and one local

+Celsius. Resolution of the remote sensor is 0.0625 degree. Local

+sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not

+supported by the driver so far, so using the default resolution of 0.5

+The driver provides the common sysfs-interface for temperatures (see

+/Documentation/hwmon/sysfs-interface under Temperatures).

+The TMP411 chip is compatible with TMP401. It provides some additional

+* Minimum and Maximum temperature measured since power-on, chip-reset

+ Exported via sysfs attributes tempX_lowest and tempX_highest.

+* Reset of historical minimum/maximum temperature measurements

+ Exported via sysfs attribute temp_reset_history. Writing 1 to this

diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf
index b6eb59384bb3..02b74899edaf 100644
--- a/Documentation/hwmon/w83627ehf
+++ b/Documentation/hwmon/w83627ehf

Addresses scanned: ISA address retrieved from Super I/O registers

http://www.nuvoton.com.tw/NR/rdonlyres/7885623D-A487-4CF9-A47F-30C5F73D6FE6/0/W83627DHG.pdf

+ Addresses scanned: ISA address retrieved from Super I/O registers

Addresses scanned: ISA address retrieved from Super I/O registers

This driver implements support for the Winbond W83627EHF, W83627EHG,

-W83627DHG and W83667HG super I/O chips. We will refer to them collectively

+W83627DHG, W83627DHG-P and W83667HG super I/O chips. We will refer to them

The chips implement three temperature sensors, five fan rotation

speed sensors, ten analog voltage sensors (only nine for the 627DHG), one

@@ -135,3 +139,6 @@ done in the driver for all register addresses.

The DHG also supports PECI, where the DHG queries Intel CPU temperatures, and

the ICH8 southbridge gets that data via PECI from the DHG, so that the

southbridge drives the fans. And the DHG supports SST, a one-wire serial bus.

+The DHG-P has an additional automatic fan speed control mode named Smart Fan

+(TM) III+. This mode is not yet supported by the driver.

diff --git a/Documentation/i2c/busses/i2c-ocores b/Documentation/i2c/busses/i2c-ocores
index cfcebb10d14e..c269aaa2f26a 100644
--- a/Documentation/i2c/busses/i2c-ocores
+++ b/Documentation/i2c/busses/i2c-ocores

@@ -20,6 +20,8 @@ platform_device with the base address and interrupt number. The

dev.platform_data of the device should also point to a struct

ocores_i2c_platform_data (see linux/i2c-ocores.h) describing the

+There is also a possibility to attach a list of i2c_board_info which

+the i2c-ocores driver will add to the bus upon creation.

@@ -36,9 +38,24 @@ static struct resource ocores_resources[] = {

+ .devices = ocores_i2c_board_info, /* optional table of devices */

+ .num_devices = ARRAY_SIZE(ocores_i2c_board_info), /* table size */

diff --git a/Documentation/i2c/busses/i2c-viapro b/Documentation/i2c/busses/i2c-viapro
index 22efedf60c87..2e758b0e9456 100644
--- a/Documentation/i2c/busses/i2c-viapro
+++ b/Documentation/i2c/busses/i2c-viapro

@@ -53,6 +56,7 @@ Your lspci -n listing must show one of these :

If none of these show up, you should look in the BIOS for settings like

diff --git a/Documentation/ide/ide.txt b/Documentation/ide/ide.txt
index 0c78f4b1d9d9..e77bebfa7b0d 100644
--- a/Documentation/ide/ide.txt
+++ b/Documentation/ide/ide.txt

@@ -216,6 +216,8 @@ Other kernel parameters for ide_core are:

* "noflush=[interface_number.device_number]" to disable flush requests

+* "nohpa=[interface_number.device_number]" to disable Host Protected Area

* "noprobe=[interface_number.device_number]" to skip probing

* "nowerr=[interface_number.device_number]" to ignore the WRERR_STAT bit

diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
index 9f09557aea39..a12ea3b586e6 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt

Anonymous finger details are sent sequentially as separate packets of ABS

events. Only the ABS_MT events are recognized as part of a finger

packet. The end of a packet is marked by calling the input_mt_sync()

-function, which generates a SYN_MT_REPORT event. The end of multi-touch

-transfer is marked by calling the usual input_sync() function.

+function, which generates a SYN_MT_REPORT event. This instructs the

+receiver to accept the data for the current finger and prepare to receive

+another. The end of a multi-touch transfer is marked by calling the usual

+input_sync() function. This instructs the receiver to act upon events

+accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new

A set of ABS_MT events with the desired properties is defined. The events

are divided into categories, to allow for partial implementation. The

@@ -27,11 +31,26 @@ minimum set consists of ABS_MT_TOUCH_MAJOR, ABS_MT_POSITION_X and

ABS_MT_POSITION_Y, which allows for multiple fingers to be tracked. If the

device supports it, the ABS_MT_WIDTH_MAJOR may be used to provide the size

of the approaching finger. Anisotropy and direction may be specified with

-ABS_MT_TOUCH_MINOR, ABS_MT_WIDTH_MINOR and ABS_MT_ORIENTATION. Devices with

-more granular information may specify general shapes as blobs, i.e., as a

-ABS_MT_BLOB_ID. Finally, the ABS_MT_TOOL_TYPE may be used to specify

-whether the touching tool is a finger or a pen or something else.

+ABS_MT_TOUCH_MINOR, ABS_MT_WIDTH_MINOR and ABS_MT_ORIENTATION. The

+ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a

+finger or a pen or something else. Devices with more granular information

+may specify general shapes as blobs, i.e., as a sequence of rectangular

+shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices

+that currently support it, the ABS_MT_TRACKING_ID event may be used to

+Here is what a minimal event sequence for a two-finger touch would look

The length of the major axis of the contact. The length should be given in

surface units. If the surface has an X times Y resolution, the largest

-possible value of ABS_MT_TOUCH_MAJOR is sqrt(X^2 + Y^2), the diagonal.

+possible value of ABS_MT_TOUCH_MAJOR is sqrt(X^2 + Y^2), the diagonal [4].

The length, in surface units, of the minor axis of the contact. If the

The length, in surface units, of the major axis of the approaching

tool. This should be understood as the size of the tool itself. The

orientation of the contact and the approaching tool are assumed to be the

The length, in surface units, of the minor axis of the approaching

The above four values can be used to derive additional information about

the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates

-The orientation of the ellipse. The value should describe half a revolution

-clockwise around the touch center. The scale of the value is arbitrary, but

-zero should be returned for an ellipse aligned along the Y axis of the

-surface. As an example, an index finger placed straight onto the axis could

-return zero orientation, something negative when twisted to the left, and

-something positive when twisted to the right. This value can be omitted if

-the touching object is circular, or if the information is not available in

+The orientation of the ellipse. The value should describe a signed quarter

+of a revolution clockwise around the touch center. The signed value range

+is arbitrary, but zero should be returned for a finger aligned along the Y

+axis of the surface, a negative value when finger is turned to the left, and

+a positive value when finger turned to the right. When completely aligned with

+the X axis, the range max should be returned. Orientation can be omitted

+if the touching object is circular, or if the information is not available

+in the kernel driver. Partial orientation support is possible if the device

+can distinguish between the two axis, but not (uniquely) any values in

+between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1]

The BLOB_ID groups several packets together into one arbitrarily shaped

contact. This is a low-level anonymous grouping, and should not be confused

-with the high-level contactID, explained below. Most kernel drivers will

-not have this capability, and can safely omit the event.

+with the high-level trackingID [5]. Most kernel drivers will not have blob

+The TRACKING_ID identifies an initiated contact throughout its life cycle

+[5]. There are currently only a few devices that support it, so this event

+The flora of different hardware unavoidably leads to some devices fitting

+better to the MT protocol than others. To simplify and unify the mapping,

+this section gives recipes for how to compute certain events.

+For devices reporting contacts as rectangular shapes, signed orientation

+cannot be obtained. Assuming X and Y are the lengths of the sides of the

+touching rectangle, here is a simple formula that retains the most

+The range of ABS_MT_ORIENTATION should be set to [0, 1], to indicate that

+the device can distinguish between a finger along the Y axis (0) and a

@@ -109,14 +158,18 @@ The kernel driver should generate an arbitrary enumeration of the set of

anonymous contacts currently on the surface. The order in which the packets

-The process of finger tracking, i.e., to assign a unique contactID to each

+The process of finger tracking, i.e., to assign a unique trackingID to each

initiated contact on the surface, is left to user space; preferably the

-multi-touch X driver [3]. In that driver, the contactID stays the same and

+multi-touch X driver [3]. In that driver, the trackingID stays the same and

unique until the contact vanishes (when the finger leaves the surface). The

problem of assigning a set of anonymous fingers to a set of identified

fingers is a euclidian bipartite matching problem at each event update, and

+There are a few devices that support trackingID in hardware. User space can

+make use of these native identifiers to reduce bandwidth and cpu usage.

time of writing (April 2009), the MT protocol is not yet merged, and the

prototype implements finger matching, basic mouse support and two-finger

scrolling. The project aims at improving the quality of current multi-touch

-functionality available in the synaptics X driver, and in addition

+functionality available in the Synaptics X driver, and in addition

diff --git a/Documentation/isdn/00-INDEX b/Documentation/isdn/00-INDEX
index 5a2d69989a8c..f6010a536590 100644
--- a/Documentation/isdn/00-INDEX
+++ b/Documentation/isdn/00-INDEX

+>>>>>>> 93af7aca44f0e82e67bda10a0fb73d383edcc8bd:Documentation/isdn/00-INDEX

- - frequently asked questions about running PPP over ISDN.

- info on "CONCAP" encapsulation protocol interface used for X.25.

+ - info on the drivers for Siemens Gigaset ISDN adapters

+ - frequently asked questions about running PPP over ISDN.

diff --git a/Documentation/isdn/INTERFACE.CAPI b/Documentation/isdn/INTERFACE.CAPI
index 786d619b36e5..686e107923ec 100644
--- a/Documentation/isdn/INTERFACE.CAPI
+++ b/Documentation/isdn/INTERFACE.CAPI

@@ -45,7 +45,7 @@ From then on, Kernel CAPI may call the registered callback functions for the

If the device becomes unusable for any reason (shutdown, disconnect ...), the

-driver has to call capi_ctr_reseted(). This will prevent further calls to the

+driver has to call capi_ctr_down(). This will prevent further calls to the

int (*load_firmware)(struct capi_ctr *ctrlr, capiloaddata *ldata)

(optional) pointer to a callback function for sending firmware and

- pointer to a callback function for performing a reset on the device,

+ (optional) pointer to a callback function for performing a reset on

void (*register_appl)(struct capi_ctr *ctrlr, u16 applid,

pointers to callback functions for registration and deregistration of

+ Calls to these functions are serialized by Kernel CAPI so that only

u16 (*send_message)(struct capi_ctr *ctrlr, struct sk_buff *skb)

pointer to a callback function for sending a CAPI message to the

+ If the method returns 0 (CAPI_NOERROR) the driver has taken ownership

+ of the skb and the caller may no longer access it. If it returns a

+ non-zero (error) value then ownership of the skb returns to the caller

+ The return value should only be used to signal problems with respect

+ to accepting or queueing the message. Errors occurring during the

+ actual processing of the message should be signaled with an

+ Calls to this function are not serialized by Kernel CAPI, ie. it must

pointer to a callback function returning the entry for the device in

system entry, /proc/capi/controllers/<n>; will be called with a

pointer to the device's capi_ctr structure as the last (data) argument

+Note: Callback functions are never called in interrupt context.

+The _cmsg structure stores the contents of a CAPI 2.0 message in an easily

+accessible form. It contains members for all possible CAPI 2.0 parameters, of

+which only those appearing in the message type currently being processed are

+Members are named after the CAPI 2.0 standard names of the parameters they

+represent. See <linux/isdn/capiutil.h> for the exact spelling. Member data

+_cstruct for CAPI parameters of type 'struct' not containing any

+ variably-sized (struct) subparameters (eg. 'Called Party Number')

+ The member is a pointer to a buffer containing the parameter in

+ CAPI encoding (length + content). It may also be NULL, which will

+ be taken to represent an empty (zero length) parameter.

+_cmstruct for CAPI parameters of type 'struct' containing 'struct'

+ The representation is a single byte containing one of the values:

+ CAPI_COMPOSE: the values of the subparameters are stored

+ individually in the corresponding _cmsg structure members

+Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert

+messages between their transport encoding described in the CAPI 2.0 standard

+and their _cmsg structure representation. Note that capi_cmsg2message() does

+not know or check the size of its destination buffer. The caller must make

+sure it is big enough to accomodate the resulting CAPI message.

@@ -166,7 +223,7 @@ int detach_capi_ctr(struct capi_ctr *ctrlr)

@@ -211,3 +268,32 @@ CAPIMSG_CONTROL(m) CAPIMSG_SETCONTROL(m, contr) Controller/PLCI/NCCI

CAPIMSG_DATALEN(m) CAPIMSG_SETDATALEN(m, len) Data Length (u16)

+ Assembles a CAPI 2.0 message from the parameters in *cmsg, storing the

+ Disassembles the CAPI 2.0 message in *msg, storing the parameters in

+unsigned capi_cmsg_header(_cmsg *cmsg, u16 ApplId, u8 Command, u8 Subcommand,

+ Fills the header part and address field of the _cmsg structure *cmsg

+ with the given values, zeroing the remainder of the structure so only

+ parameters with non-default values need to be changed before sending

+ Sets the low bit of the Subcommand field in *cmsg, thereby converting

+ Returns the CAPI 2.0 message name corresponding to the given command

+ and subcommand values, as a static ASCII string. The return value may

+ be NULL if the command/subcommand is not one of those defined in the

diff --git a/Documentation/isdn/README.gigaset b/Documentation/isdn/README.gigaset
index 02c0e9341dd8..f9963103ae3d 100644
--- a/Documentation/isdn/README.gigaset
+++ b/Documentation/isdn/README.gigaset

configuration files and chat scripts in the gigaset-VERSION/ppp directory

in the driver packages from http://sourceforge.net/projects/gigaset307x/.

Please note that the USB drivers are not able to change the state of the

- control lines (the M105 driver can be configured to use some undocumented

- control requests, if you really need the control lines, though). This means

- you must use "Stupid Mode" if you are using wvdial or you should use the

+ control lines. This means you must use "Stupid Mode" if you are using

You must also assure that the ppp_async module is loaded with the parameter

You can also use /sys/class/tty/ttyGxy/cidmode for changing the CID mode

- The Gigaset M105 USB data box understands a couple of useful, but

- undocumented USB commands. These requests are not used in normal

- operation (for wireless access to the base), but are needed for access

- to the M105's own configuration mode (registration to the base, baudrate

- and line format settings, device status queries) via the gigacontr

- utility. Their use is controlled by the kernel configuration option

- "Support for undocumented USB requests" (CONFIG_GIGASET_UNDOCREQ). If you

- encounter error code -ENOTTY when trying to use some features of the

- M105, try setting that option to "y" via 'make {x,menu}config' and

+ The main purpose of the ser_gigaset and usb_gigaset drivers is to allow

+ the M101 and M105 wireless devices to be used as ISDN devices for ISDN

+ connections through a Gigaset base. Therefore they assume that the device

+ If the M101/M105 device is not registered to a base, initialization of

+ the device fails, and a corresponding error message is logged by the

+ driver. In that situation, a restricted set of functions is available

+ which includes, in particular, those necessary for registering the device

+ to a base or for switching it between Fixed Part and Portable Part

Select Unimodem mode for all DECT data adapters. (see section 2.4.)

- You want to configure your USB DECT data adapter (M105) but gigacontr

- reports an error: "/dev/ttyGU0: Inappropriate ioctl for device".

- Recompile the usb_gigaset driver with the kernel configuration option

+ Check whether your M10x wireless device is correctly registered to the

diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index 26a7c0a93193..849b5e56d06f 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt

@@ -35,48 +35,26 @@ new .config files to see the differences:

-======================================================================

- The Search function searches for kernel configuration symbol

- names, so you have to know something close to what you are

- For search help, enter / followed TAB-TAB-TAB (to highlight

- <Help>) and Enter. This will tell you that you can also use

- regular expressions (regexes) in the search string, so if you

______________________________________________________________________

-It is possible to select different color themes using the variable

+This environment variable can be used to specify a default kernel config

+If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not

+break symlinks when .config is a symlink to somewhere else.

- mono => selects colors suitable for monochrome displays

- blackbg => selects a color scheme with black background

- classic => theme with blue background. The classic look

- bluetitle => a LCD friendly version of classic. (default)

+If this environment variable exists and is non-null, the timestamp line

______________________________________________________________________

+Environment variables for '{allyes/allmod/allno/rand}config'

This enables you to create "miniature" config (miniconfig) or custom

config files containing just the config symbols that you are interested

in. Then the kernel config system generates the full .config file,

-including dependencies of your miniconfig file, based on the miniconfig

This 'KCONFIG_ALLCONFIG' file is a config file which contains

(usually a subset of all) preset config symbols. These variable

@@ -113,26 +90,14 @@ These examples will disable most options (allnoconfig) but enable or

disable the options that are explicitly listed in the specified

+______________________________________________________________________

If this variable has a non-blank value, it prevents silent kernel

-This environment variable can be used to specify a default kernel config

-If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not

-break symlinks when .config is a symlink to somewhere else.

-If this environment variable exists and is non-null, the timestamp line

This environment variable can be set to specify the path & name of the

"autoconf.h" (header) file. Its default value is "include/linux/autoconf.h".

+======================================================================

+ The Search function searches for kernel configuration symbol

+ names, so you have to know something close to what you are

+ For search help, enter / followed TAB-TAB-TAB (to highlight

+ <Help>) and Enter. This will tell you that you can also use

+ regular expressions (regexes) in the search string, so if you

______________________________________________________________________

-----------------------------------------------------------------------

+It is possible to select different color themes using the variable

+ mono => selects colors suitable for monochrome displays

+ blackbg => selects a color scheme with black background

+ classic => theme with blue background. The classic look

+ bluetitle => a LCD friendly version of classic. (default)

======================================================================

diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt
index b1096da953c8..0767cf69c69e 100644
--- a/Documentation/kbuild/modules.txt
+++ b/Documentation/kbuild/modules.txt

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 3f4bc840da8b..cab61d842259 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt

@@ -108,7 +108,7 @@ There are two possible methods of using Kdump.

2) Or use the system kernel binary itself as dump-capture kernel and there is

no need to build a separate dump-capture kernel. This is possible

- only with the architecutres which support a relocatable kernel. As

+ only with the architectures which support a relocatable kernel. As

of today, i386, x86_64, ppc64 and ia64 architectures support relocatable

@@ -222,7 +222,7 @@ Dump-capture kernel config options (Arch Dependent, ia64)

----------------------------------------------------------

- No specific options are required to create a dump-capture kernel

- for ia64, other than those specified in the arch idependent section

+ for ia64, other than those specified in the arch independent section

above. This means that it is possible to use the system kernel

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 9243dd84f4d6..5578248c18a4 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt

@@ -328,11 +328,6 @@ and is between 256 and 4096 characters. It is defined in the file

@@ -496,6 +491,13 @@ and is between 256 and 4096 characters. It is defined in the file

@@ -544,6 +546,10 @@ and is between 256 and 4096 characters. It is defined in the file

+ consoleblank= [KNL] The console blank (screen saver) timeout in

@@ -645,6 +651,13 @@ and is between 256 and 4096 characters. It is defined in the file

@@ -751,12 +764,25 @@ and is between 256 and 4096 characters. It is defined in the file

@@ -872,11 +898,8 @@ and is between 256 and 4096 characters. It is defined in the file

@@ -913,6 +936,12 @@ and is between 256 and 4096 characters. It is defined in the file

@@ -1055,13 +1084,17 @@ and is between 256 and 4096 characters. It is defined in the file

@@ -1380,7 +1413,7 @@ and is between 256 and 4096 characters. It is defined in the file

@@ -1525,6 +1558,10 @@ and is between 256 and 4096 characters. It is defined in the file

+ noxsave [BUGS=X86] Disables x86 extended register state save

nohlt [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or

@@ -1561,6 +1598,9 @@ and is between 256 and 4096 characters. It is defined in the file

noinitrd [RAM] Tells the kernel not to load any configured

+ nointremap [X86-64, Intel-IOMMU] Do not enable interrupt

@@ -1646,6 +1686,14 @@ and is between 256 and 4096 characters. It is defined in the file

diff --git a/Documentation/kmemcheck.txt b/Documentation/kmemcheck.txt
new file mode 100644
index 000000000000..363044609dad
--- /dev/null
+++ b/Documentation/kmemcheck.txt

+kmemcheck is a debugging feature for the Linux Kernel. More specifically, it

+is a dynamic checker that detects and warns about some uses of uninitialized

+Userspace programmers might be familiar with Valgrind's memcheck. The main

+difference between memcheck and kmemcheck is that memcheck works for userspace

+programs only, and kmemcheck works for the kernel only. The implementations

+are of course vastly different. Because of this, kmemcheck is not as accurate

+as memcheck, but it turns out to be good enough in practice to discover real

+programmer errors that the compiler is not able to find through static

+Enabling kmemcheck on a kernel will probably slow it down to the extent that

+the machine will not be usable for normal workloads such as e.g. an

+interactive desktop. kmemcheck will also cause the kernel to use about twice

+as much memory as normal. For this reason, kmemcheck is strictly a debugging

+kmemcheck can only be downloaded using git. If you want to write patches

+against the current code, you should use the kmemcheck development branch of

+the tip tree. It is also possible to use the linux-next tree, which also

+Assuming that you've already cloned the linux-2.6.git repository, all you

+ $ git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git

+And to check out a new local branch with the kmemcheck code:

+General instructions for the -tip tree can be found here:

+kmemcheck only works for the x86 (both 32- and 64-bit) platform. A number of

+configuration variables must have specific settings in order for the kmemcheck

+ This option is located under "General setup" / "Optimize for size".

+ Without this, gcc will use certain optimizations that usually lead to

+ false positive warnings from kmemcheck. An example of this is a 16-bit

+ field in a struct, where gcc may load 32 bits, then discard the upper

+ 16 bits. kmemcheck sees only the 32-bit load, and may trigger a

+ warning for the upper 16 bits (if they're uninitialized).

+ This option is located under "General setup" / "Choose SLAB

+ This option is located under "Kernel hacking" / "Tracers" / "Kernel

+ When function tracing is compiled in, gcc emits a call to another

+ function at the beginning of every function. This means that when the

+ page fault handler is called, the ftrace framework will be called

+ before kmemcheck has had a chance to handle the fault. If ftrace then

+ modifies memory that was tracked by kmemcheck, the result is an

+ This option is located under "Kernel hacking" / "Debug page memory

+In addition, I highly recommend turning on CONFIG_DEBUG_INFO=y. This is also

+located under "Kernel hacking". With this, you will be able to get line number

+information from the kmemcheck warnings, which is extremely valuable in

+debugging a problem. This option is not mandatory, however, because it slows

+down the compilation process and produces a much bigger kernel image.

+Now the kmemcheck menu should be visible (under "Kernel hacking" / "kmemcheck:

+trap use of uninitialized memory"). Here follows a description of the

+ This must be enabled in order to use kmemcheck at all...

+ o CONFIG_KMEMCHECK_[DISABLED | ENABLED | ONESHOT]_BY_DEFAULT

+ This option controls the status of kmemcheck at boot-time. "Enabled"

+ will enable kmemcheck right from the start, "disabled" will boot the

+ kernel as normal (but with the kmemcheck code compiled in, so it can

+ be enabled at run-time after the kernel has booted), and "one-shot" is

+ a special mode which will turn kmemcheck off automatically after

+ If you are using kmemcheck to actively debug a problem, then you

+ The one-shot mode is mostly useful in automated test setups because it

+ can prevent floods of warnings and increase the chances of the machine

+ surviving in case something is really wrong. In other cases, the one-

+ shot mode could actually be counter-productive because it would turn

+ itself off at the very first error -- in the case of a false positive

+ too -- and this would come in the way of debugging the specific

+ If you would like to use your kernel as normal, but with a chance to

+ enable kmemcheck in case of some problem, it might be a good idea to

+ choose "disabled" here. When kmemcheck is disabled, most of the run-

+ time overhead is not incurred, and the kernel will be almost as fast

+ Select the maximum number of error reports to store in an internal

+ (fixed-size) buffer. Since errors can occur virtually anywhere and in

+ any context, we need a temporary storage area which is guaranteed not

+ to generate any other page faults when accessed. The queue will be

+ emptied as soon as a tasklet may be scheduled. If the queue is full,

+ The default value of 64 is probably fine. If some code produces more

+ than 64 errors within an irqs-off section, then the code is likely to

+ produce many, many more, too, and these additional reports seldom give

+ any more information (the first report is usually the most valuable

+ This number might have to be adjusted if you are not using serial

+ console or similar to capture the kernel log. If you are using the

+ "dmesg" command to save the log, then getting a lot of kmemcheck

+ warnings might overflow the kernel log itself, and the earlier reports

+ will get lost in that way instead. Try setting this to 10 or so on

+ Select the number of shadow bytes to save along with each entry of the

+ error-report queue. These bytes indicate what parts of an allocation

+ are initialized, uninitialized, etc. and will be displayed when an

+ error is detected to help the debugging of a particular problem.

+ The number entered here is actually the logarithm of the number of

+ bytes that will be saved. So if you pick for example 5 here, kmemcheck

+ The default value should be fine for debugging most problems. It also

+ This option (when enabled) works around certain GCC optimizations that

+ produce 32-bit reads from 16-bit variables where the upper 16 bits are

+ The default value (enabled) is recommended. This may of course hide

+ some real errors, but disabling it would probably produce a lot of

+ This option silences warnings that would be generated for bit-field

+ accesses where not all the bits are initialized at the same time. This

+ This option is probably obsolete, or it should be replaced with

+ the kmemcheck-/bitfield-annotations for the code in question. The

+First some information about the command-line options. There is only one

+option specific to kmemcheck, and this is called "kmemcheck". It can be used

+to override the default mode as chosen by the CONFIG_KMEMCHECK_*_BY_DEFAULT

+If SLUB debugging has been enabled in the kernel, it may take precedence over

+kmemcheck in such a way that the slab caches which are under SLUB debugging

+will not be tracked by kmemcheck. In order to ensure that this doesn't happen

+(even though it shouldn't by default), use SLUB's boot option "slub_debug",

+In fact, this option may also be used for fine-grained control over SLUB vs.

+kmemcheck. For example, if the command line includes "kmemcheck=1

+slub_debug=,dentry", then SLUB debugging will be used only for the "dentry"

+slab cache, and with kmemcheck tracking all the other caches. This is advanced

+When the kernel has booted, it is possible to enable or disable kmemcheck at

+run-time. WARNING: This feature is still experimental and may cause false

+positive warnings to appear. Therefore, try not to use this. If you find that

+it doesn't work properly (e.g. you see an unreasonable amount of warnings), I

+Use the file /proc/sys/kernel/kmemcheck for this purpose, e.g.:

+ $ echo 0 > /proc/sys/kernel/kmemcheck # disables kmemcheck

+The numbers are the same as for the kmemcheck= command-line option.

+WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88003e4a2024)

+80000000000000000000000000000000000000000088ffff0000000000000000

+ i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u

+Pid: 1856, comm: ntpdate Not tainted 2.6.29-rc5 #264 945P-A

+RIP: 0010:[<ffffffff8104ede8>] [<ffffffff8104ede8>] __dequeue_signal+0xc8/0x190

+RAX: 0000000000000030 RBX: ffff88003d4ea968 RCX: 0000000000000009

+RDX: ffff88003e5d6018 RSI: ffff88003e5d6024 RDI: ffff88003cdf7e84

+RBP: ffff88003cdf7db8 R08: ffff88003e5d6000 R09: 0000000000000000

+R10: 0000000000000080 R11: 0000000000000000 R12: 000000000000000e

+R13: ffff88003cdf7e78 R14: ffff88003d530710 R15: ffff88003d5a98c8

+FS: 0000000000000000(0000) GS:ffff880001982000(0063) knlGS:00000

+CR2: ffff88003f806ea0 CR3: 000000003c036000 CR4: 00000000000006a0

+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

+DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400

+The single most valuable information in this report is the RIP (or EIP on 32-

+bit) value. This will help us pinpoint exactly which instruction that caused

+If your kernel was compiled with CONFIG_DEBUG_INFO=y, then all we have to do

+is give this address to the addr2line program, like this:

+The "-e vmlinux" tells addr2line which file to look in. IMPORTANT: This must

+be the vmlinux of the kernel that produced the warning in the first place! If

+not, the line number information will almost certainly be wrong.

+The "-i" tells addr2line to also print the line numbers of inlined functions.

+In this case, the flag was very important, because otherwise, it would only

+have printed the first line, which is just a call to memcpy(), which could be

+called from a thousand places in the kernel, and is therefore not very useful.

+These inlined functions would not show up in the stack trace above, simply

+because the kernel doesn't load the extra debugging information. This

+technique can of course be used with ordinary kernel oopses as well.

+In this case, it's the caller of memcpy() that is interesting, and it can be

+281 static inline void copy_siginfo(struct siginfo *to, struct siginfo *from)

+286 /* _sigchld is currently the largest know union member */

+287 memcpy(to, from, __ARCH_SI_PREAMBLE_SIZE + sizeof(from->_sifields._sigchld));

+Since this was a read (kmemcheck usually warns about reads only, though it can

+warn about writes to unallocated or freed memory as well), it was probably the

+"from" argument which contained some uninitialized bytes. Following the chain

+of calls, we move upwards to see where "from" was allocated or initialized,

+359 static void collect_signal(int sig, struct sigpending *list, siginfo_t *info)

+Here, it is &first->info that is being passed on to copy_siginfo(). The

+variable "first" was found on a list -- passed in as the second argument to

+collect_signal(). We continue our journey through the stack, to figure out

+where the item on "list" was allocated or initialized. We move to line 410:

+395 static int __dequeue_signal(struct sigpending *pending, sigset_t *mask,

+Now we need to follow the "pending" pointer, since that is being passed on to

+collect_signal() as "list". At this point, we've run out of lines from the

+"addr2line" output. Not to worry, we just paste the next addresses from the

+ $ addr2line -e vmlinux -i ffffffff8104f04e ffffffff81050bd8 \

+Remember that since these addresses were found on the stack and not as the

+RIP value, they actually point to the _next_ instruction (they are return

+addresses). This becomes obvious when we look at the code for line 446:

+422 int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info)

+431 signr = __dequeue_signal(&tsk->signal->shared_pending,

+436 * itimers are process shared and we restart periodic

+437 * itimers in the signal delivery path to prevent DoS

+438 * attacks in the high resolution timer case. This is

+440 * itimers, as the SIGALRM is a legacy signal and only

+So instead of looking at 446, we should be looking at 431, which is the line

+that executes just before 446. Here we see that what we are looking for is

+Our next task is now to figure out which function that puts items on this

+"shared_pending" list. A crude, but efficient tool, is git grep:

+ kernel/signal.c:828: pending = group ? &t->signal->shared_pending : &t->pending;

+ kernel/signal.c:1339: pending = group ? &t->signal->shared_pending : &t->pending;

+There were more results, but none of them were related to list operations,

+and these were the only assignments. We inspect the line numbers more closely

+and find that this is indeed where items are being added to the list:

+816 static int send_signal(int sig, struct siginfo *info, struct task_struct *t,

+828 pending = group ? &t->signal->shared_pending : &t->pending;

+851 q = __sigqueue_alloc(t, GFP_ATOMIC, (sig < SIGRTMIN &&

+1309 int send_sigqueue(struct sigqueue *q, struct task_struct *t, int group)

+1339 pending = group ? &t->signal->shared_pending : &t->pending;

+In the first case, the list element we are looking for, "q", is being returned

+from the function __sigqueue_alloc(), which looks like an allocation function.

+187 static struct sigqueue *__sigqueue_alloc(struct task_struct *t, gfp_t flags,

+194 * We won't get problems with the target's UID changing under us

+195 * because changing it requires RCU be used, and if t != current, the

+196 * caller must be holding the RCU readlock (by way of a spinlock) and

+We see that this function initializes q->list, q->flags, and q->user. It seems

+that now is the time to look at the definition of "struct sigqueue", e.g.:

+And, you might remember, it was a memcpy() on &first->info that caused the

+warning, so this makes perfect sense. It also seems reasonable to assume that

+it is the caller of __sigqueue_alloc() that has the responsibility of filling

+But just which fields of the struct were uninitialized? Let's look at

+WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88003e4a2024)

+80000000000000000000000000000000000000000088ffff0000000000000000

+ i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u

+These first two lines are the memory dump of the memory object itself, and the

+shadow bytemap, respectively. The memory object itself is in this case

+&first->info. Just beware that the start of this dump is NOT the start of the

+object itself! The position of the caret (^) corresponds with the address of

+ a - unallocated (memory has been allocated by the slab layer, but has not

+ f - freed (memory has been allocated by the slab layer, but has been freed

+In order to figure out where (relative to the start of the object) the

+uninitialized memory was located, we have to look at the disassembly. For

+RIP: 0010:[<ffffffff8104ede8>] [<ffffffff8104ede8>] __dequeue_signal+0xc8/0x190

+ $ objdump -d --no-show-raw-insn vmlinux | grep -C 8 ffffffff8104ede8:

+ ffffffff8104edcf: js ffffffff8104ee88 <__dequeue_signal+0x168>

+ ffffffff8104edec: je ffffffff8104edf0 <__dequeue_signal+0xd0>

+ ffffffff8104edf2: je ffffffff8104edf5 <__dequeue_signal+0xd5>

+ ffffffff8104edf8: callq ffffffff8104de60 <__sigqueue_free>

+As expected, it's the "rep movsl" instruction from the memcpy() that causes

+the warning. We know about REP MOVSL that it uses the register RCX to count

+the number of remaining iterations. By taking a look at the register dump

+again (from the kmemcheck report), we can figure out how many bytes were left

+RAX: 0000000000000030 RBX: ffff88003d4ea968 RCX: 0000000000000009

+By looking at the disassembly, we also see that %ecx is being loaded with the

+value $0xc just before (ffffffff8104edd8), so we are very lucky. Keep in mind

+that this is the number of iterations, not bytes. And since this is a "long"

+operation, we need to multiply by 4 to get the number of bytes. So this means

+that the uninitialized value was encountered at 4 * (0xc - 0x9) = 12 bytes

+We can now try to figure out which field of the "struct siginfo" that was not

+On 64-bit, the int is 4 bytes long, so it must the the union member that has

+Actually, it seems that the union member is located at offset 0x10 -- which

+means that gcc has inserted 4 bytes of padding between the members si_code

+and _sifields. We can now get a fuller picture of the memory dump:

+80000000000000000000000000000000000000000088ffff0000000000000000

+ i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u

+This allows us to realize another important fact: si_code contains the value

+0x80. Remember that x86 is little endian, so the first 4 bytes "80000000" are

+really the number 0x00000080. With a bit of research, we find that this is

+actually the constant SI_KERNEL defined in include/asm-generic/siginfo.h:

+144 #define SI_KERNEL 0x80 /* sent by the kernel from somewhere */

+This macro is used in exactly one place in the x86 kernel: In send_signal()

+816 static int send_signal(int sig, struct siginfo *info, struct task_struct *t,

+828 pending = group ? &t->signal->shared_pending : &t->pending;

+851 q = __sigqueue_alloc(t, GFP_ATOMIC, (sig < SIGRTMIN &&

+Not only does this match with the .si_code member, it also matches the place

+we found earlier when looking for where siginfo_t objects are enqueued on the

+So to sum up: It seems that it is the padding introduced by the compiler

+between two struct fields that is uninitialized, and this gets reported when

+we do a memcpy() on the struct. This means that we have identified a false

+Normally, kmemcheck will not report uninitialized accesses in memcpy() calls

+when both the source and destination addresses are tracked. (Instead, we copy

+the shadow bytemap as well). In this case, the destination address clearly

+was not tracked. We can dig a little deeper into the stack trace from above:

+And we clearly see that the destination siginfo object is located on the

+804 signr = get_signal_to_deliver(&info, &ka, regs, NULL);

+And this &info is what eventually gets passed to copy_siginfo() as the

+Now, even though we didn't find an actual error here, the example is still a

+good one, because it shows how one would go about to find out what the report

+There are a few different ways to make annotations in the source code that

+will keep kmemcheck from checking and reporting certain allocations. Here

+ This flag can be passed to kmalloc() or kmem_cache_alloc() (therefore

+ also to other functions that end up calling one of these) to indicate

+ that the allocation should not be tracked because it would lead to

+ a false positive report. This is a "big hammer" way of silencing

+ kmemcheck; after all, even if the false positive pertains to

+ particular field in a struct, for example, we will now lose the

+ ability to find (real) errors in other parts of the same struct.

+ /* No warnings will ever trigger on accessing any part of x */

+ x = kmalloc(sizeof *x, GFP_KERNEL | __GFP_NOTRACK_FALSE_POSITIVE);

+ o kmemcheck_bitfield_begin(name)/kmemcheck_bitfield_end(name) and

+ The first two of these three macros can be used inside struct

+ definitions to signal, respectively, the beginning and end of a

+ bitfield. Additionally, this will assign the bitfield a name, which

+ kmemcheck_annotate_bitfield() at the point of allocation, to indicate

+ /* No warnings will trigger on accessing the bitfield of x */

+ Note that kmemcheck_annotate_bitfield() can be used even before the

+ return value of kmalloc() is checked -- in other words, passing NULL

+As we have seen, kmemcheck will produce false positive reports. Therefore, it

+is not very wise to blindly post kmemcheck warnings to mailing lists and

+maintainers. Instead, I encourage maintainers and developers to find errors

+in their own code. If you get a warning, you can try to work around it, try

+to figure out if it's a real error or not, or simply ignore it. Most

+developers know their own code and will quickly and efficiently determine the

+root cause of a kmemcheck report. This is therefore also the most efficient

+That said, we (the kmemcheck maintainers) will always be on the lookout for

+false positives that we can annotate and silence. So whatever you find,

+please drop us a note privately! Kernel configs and steps to reproduce (if

+kmemcheck works by marking memory pages non-present. This means that whenever

+somebody attempts to access the page, a page fault is generated. The page

+fault handler notices that the page was in fact only hidden, and so it calls

+When the investigations are completed, kmemcheck "shows" the page by marking

+it present (as it would be under normal circumstances). This way, the

+But after the instruction has been executed, we should hide the page again, so

+that we can catch the next access too! Now kmemcheck makes use of a debugging

+feature of the processor, namely single-stepping. When the processor has

+finished the one instruction that generated the memory access, a debug

+exception is raised. From here, we simply hide the page again and continue

+execution, this time with the single-stepping feature turned off.

+kmemcheck requires some assistance from the memory allocator in order to work.

+ 1. Tell kmemcheck about newly allocated pages and pages that are about to

+ be freed. This allows kmemcheck to set up and tear down the shadow memory

+ for the pages in question. The shadow memory stores the status of each

+ byte in the allocation proper, e.g. whether it is initialized or

+ 2. Tell kmemcheck which parts of memory should be marked uninitialized.

+ There are actually a few more states, such as "not yet allocated" and

+If a slab cache is set up using the SLAB_NOTRACK flag, it will never return

+If a slab cache is NOT set up using the SLAB_NOTRACK flag, callers can still

+request memory with the __GFP_NOTRACK or __GFP_NOTRACK_FALSE_POSITIVE flags.

+This does not prevent the page faults from occurring, however, but marks the

+object in question as being initialized so that no warnings will ever be

+Currently, the SLAB and SLUB allocators are supported by kmemcheck.

diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
new file mode 100644
index 000000000000..0112da3b9ab8
--- /dev/null
+++ b/Documentation/kmemleak.txt

+Kmemleak provides a way of detecting possible kernel memory leaks in a

+(http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors),

+with the difference that the orphan objects are not freed but only

+reported via /sys/kernel/debug/kmemleak. A similar method is used by the

+Valgrind tool (memcheck --leak-check) to detect the memory leaks in

+CONFIG_DEBUG_KMEMLEAK in "Kernel hacking" has to be enabled. A kernel

+thread scans the memory every 10 minutes (by default) and prints any new

+unreferenced objects found. To trigger an intermediate scan and display

+Note that the orphan objects are listed in the order they were allocated

+and one object at the beginning of the list may cause other subsequent

+Memory scanning parameters can be modified at run-time by writing to the

+/sys/kernel/debug/kmemleak file. The following parameters are supported:

+ scan=<secs> - set the automatic memory scanning period in seconds (0

+Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on

+The memory allocations via kmalloc, vmalloc, kmem_cache_alloc and

+friends are traced and the pointers, together with additional

+information like size and stack trace, are stored in a prio search tree.

+The corresponding freeing function calls are tracked and the pointers

+An allocated block of memory is considered orphan if no pointer to its

+start address or to any location inside the block can be found by

+scanning the memory (including saved registers). This means that there

+might be no way for the kernel to pass the address of the allocated

+block to a freeing function and therefore the block is considered a

+ 1. mark all objects as white (remaining white objects will later be

+ 2. scan the memory starting with the data section and stacks, checking

+ the values against the addresses stored in the prio search tree. If

+ a pointer to a white object is found, the object is added to the

+ 3. scan the gray objects for matching addresses (some white objects

+ can become gray and added at the end of the gray list) until the

+ 4. the remaining white objects are considered orphan and reported via

+Some allocated memory blocks have pointers stored in the kernel's

+internal data structures and they cannot be detected as orphans. To

+avoid this, kmemleak can also store the number of values pointing to an

+address inside the block address range that need to be found so that the

+block is not considered a leak. One example is __vmalloc().

+See the include/linux/kmemleak.h header for the functions prototype.

+kmemleak_ignore - do not scan or report an object as leak

+kmemleak_scan_area - add scan areas inside a memory block

+kmemleak_erase - erase an old value in a pointer variable

+kmemleak_alloc_recursive - as kmemleak_alloc but checks the recursiveness

+kmemleak_free_recursive - as kmemleak_free but checks the recursiveness

+The false negatives are real memory leaks (orphan objects) but not

+reported by kmemleak because values found during the memory scanning

+point to such objects. To reduce the number of false negatives, kmemleak

+provides the kmemleak_ignore, kmemleak_scan_area, kmemleak_no_scan and

+kmemleak_erase functions (see above). The task stacks also increase the

+amount of false negatives and their scanning is not enabled by default.

+The false positives are objects wrongly reported as being memory leaks

+(orphan). For objects known not to be leaks, kmemleak provides the

+kmemleak_not_leak function. The kmemleak_ignore could also be used if

+the memory block is known not to contain other pointers and it will no

+Some of the reported leaks are only transient, especially on SMP

+systems, because of pointers temporarily stored in CPU registers or

+stacks. Kmemleak defines MSECS_MIN_AGE (defaulting to 1000) representing

+the minimum age of an object to be reported as a memory leak.

+The main drawback is the reduced performance of memory allocation and

+freeing. To avoid other penalties, the memory scanning is only performed

+when the /sys/kernel/debug/kmemleak file is read. Anyway, this tool is

+intended for debugging purposes where the performance might not be the

+To keep the algorithm simple, kmemleak scans for values pointing to any

+address inside a block's address range. This may lead to an increased

+number of false negatives. However, it is likely that a real memory leak

+Another source of false negatives is the data stored in non-pointer

+values. In a future version, kmemleak could only scan the pointer

+members in the allocated structures. This feature would solve many of

+The tool can report false positives. These are cases where an allocated

+block doesn't need to be freed (some cases in the init_call functions),

+the pointer is calculated by other methods than the usual container_of

+macro or the pointer is stored in a location not scanned by kmemleak.

+Page allocations and ioremap are not tracked. Only the ARM and x86

diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt
index b2e374586bd8..c79ab996dada 100644
--- a/Documentation/kobject.txt
+++ b/Documentation/kobject.txt

There is a helper function to both initialize and add the kobject to the

-kernel at the same time, called supprisingly enough kobject_init_and_add():

+kernel at the same time, called surprisingly enough kobject_init_and_add():

int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype,

diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
index 1e7a769a10f9..053037a1fe6d 100644
--- a/Documentation/kprobes.txt
+++ b/Documentation/kprobes.txt

@@ -507,9 +507,9 @@ http://www.linuxsymposium.org/2006/linuxsymposium_procv2.pdf (pages 101-115)

With recent kernels (> 2.6.20) the list of registered kprobes is visible

-under the /debug/kprobes/ directory (assuming debugfs is mounted at /debug).

+under the /sys/kernel/debug/kprobes/ directory (assuming debugfs is mounted at //sys/kernel/debug).

-/debug/kprobes/list: Lists all registered probes on the system

+/sys/kernel/debug/kprobes/list: Lists all registered probes on the system

@@ -525,7 +525,7 @@ virtual addresses that correspond to modules that've been unloaded),

such probes are marked with [GONE]. If the probe is temporarily disabled,

+/sys/kernel/debug/kprobes/enabled: Turn kprobes ON/OFF forcibly.

Provides a knob to globally and forcibly turn registered kprobes ON or OFF.

By default, all kprobes are enabled. By echoing "0" to this file, all

diff --git a/Documentation/laptops/acer-wmi.txt b/Documentation/laptops/acer-wmi.txt
index 5ee2a02b3b40..0768fcc3ba3e 100644
--- a/Documentation/laptops/acer-wmi.txt
+++ b/Documentation/laptops/acer-wmi.txt

@@ -40,7 +40,7 @@ NOTE: The Acer Aspire One is not supported hardware. It cannot work with

acer-wmi until Acer fix their ACPI-WMI implementation on them, so has been

-Please see the website for the current list of known working hardare:

+Please see the website for the current list of known working hardware:

diff --git a/Documentation/laptops/sony-laptop.txt b/Documentation/laptops/sony-laptop.txt
index 8b2bc1572d98..23ce7d350d1a 100644
--- a/Documentation/laptops/sony-laptop.txt
+++ b/Documentation/laptops/sony-laptop.txt

@@ -22,7 +22,7 @@ If your laptop model supports it, you will find sysfs files in the

directory. You will be able to query and set the current screen

actual_brightness reading from this file will query the HW

diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt
index e7e9a69069e1..78e354b42f67 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt

In addition to the EV_KEY events, thinkpad-acpi may also issue EV_SW

-SW_RFKILL_ALL T60 and later hardare rfkill rocker switch

+SW_RFKILL_ALL T60 and later hardware rfkill rocker switch

SW_TABLET_MODE Tablet ThinkPads HKEY events 0x5009 and 0x500A

diff --git a/Documentation/lguest/Makefile b/Documentation/lguest/Makefile
index 1f4f9e888bd1..28c8cdfcafd8 100644
--- a/Documentation/lguest/Makefile
+++ b/Documentation/lguest/Makefile

# This creates the demonstration utility "lguest" which runs a Linux guest.

-CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE

+CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE

diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c
index d36fcc0f2715..9ebcd6ef361b 100644
--- a/Documentation/lguest/lguest.c
+++ b/Documentation/lguest/lguest.c

/* The maximum guest physical address allowed, and maximum possible. */

/* a per-cpu variable indicating whose vcpu is currently running */

- /* Summary information about the devices in our list: ready to pass to

- /* The this device's descriptor, as mapped into the Guest. */

+ /* The device's descriptor, as mapped into the Guest. */

+ /* We can't trust desc values once Guest has booted: we use these. */

- /* If handle_input is set, it wants to be called when this file

- /* Handle status being finalized (ie. feature bits stable). */

- /* The routine to call when the Guest pings us, or timeout. */

- void (*handle_output)(int fd, struct virtqueue *me, bool timeout);

+ /* Function for the thread which is servicing this virtqueue. */

/* Remember the arguments to the program so we can "reboot" */

-/* Since guest is UP and we don't run at the same time, we don't need barriers.

- * But I include them in the code in case others copy it. */

+/* We have to be careful with barriers: our devices are all run in separate

+ * threads and so we need to make sure that changes visible to the Guest happen

@@ -245,7 +238,7 @@ static void iov_consume(struct iovec iov[], unsigned num_iov, unsigned len)

/*L:100 The Launcher code itself takes us out into userspace, that scary place

@@ -505,99 +498,19 @@ static void concat(char *dst, char *args[])

* saw the arguments it expects when we looked at initialize() in lguest_user.c:

* the base of Guest "physical" memory, the top physical page to allow and the

- /* We return the /dev/lguest file descriptor to control this Guest */

- * With console, block and network devices, we can have lots of input which we

- * need to process. We could try to tell the kernel what file descriptors to

- * watch, but handing a file descriptor mask through to the kernel is fairly

- * Instead, we clone off a thread which watches the file descriptors and writes

- * the LHREQ_BREAK command to the /dev/lguest file descriptor to tell the Host

- * stop running the Guest. This causes the Launcher to return from the

- * /dev/lguest read with -EAGAIN, where it will write to /dev/lguest to reset

- * This, of course, is merely a different *kind* of icky.

- * Given my well-known antipathy to threads, I'd prefer to use processes. But

- * it's easier to share Guest memory with threads, and trivial to share the

- /* Close the write end of the pipe: only the Launcher has it open. */

- /* Wait until input is ready from one of the devices. */

- /* Send LHREQ_BREAK command to snap the Launcher out of it. */

- pwrite(waker_fds.lguest_fd, args, sizeof(args), cpu_id);

-/* This routine just sets up a pipe to the Waker process. */

- /* This pipe is closed when Launcher dies, telling Waker. */

- if (clone(waker, malloc(4096) + 4096, CLONE_VM | SIGCHLD, NULL) == -1)

@@ -623,49 +536,90 @@ static void *_check_pointer(unsigned long addr, unsigned int size,

/* Each buffer in the virtqueues is actually a chain of descriptors. This

* function returns the next descriptor in the chain, or vq->vring.num if we're

-static unsigned next_desc(struct virtqueue *vq, unsigned int i)

/* If this descriptor says it doesn't chain, we're done. */

/* Check they're not leading us off end of descriptors. */

/* Make sure compiler knows to grab that: we don't want it changing! */

+/* This actually sends the interrupt for this virtqueue */

+ /* If they don't want an interrupt, don't send one, unless empty. */

+ if ((vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT)

+ /* Send the Guest an interrupt tell them we used something up. */

/* This looks in the virtqueue and for the first available buffer, and converts

* it to an iovec for convenient access. Since descriptors consist of some

* number of output then some number of input descriptors, it's actually two

* iovecs, but we pack them into one and note how many of each there were.

- * This function returns the descriptor number found, or vq->vring.num (which

- * is never a valid descriptor number) if none was found. */

+ * This function returns the descriptor number found. */

+ /* They could have slipped one in as we were doing that: make

+ /* Nothing new? Wait for eventfd to tell us they refilled. */

+ if (read(vq->eventfd, &event, sizeof(event)) != sizeof(event))

/* Check it isn't doing very strange things with descriptor numbers. */

if ((u16)(vq->vring.avail->idx - last_avail) > vq->vring.num)

- /* If there's nothing new since last we looked, return invalid. */

/* Grab the next descriptor number they're advertising, and increment

head = vq->vring.avail->ring[last_avail % vq->vring.num];

@@ -678,15 +632,28 @@ static unsigned get_vq_desc(struct virtqueue *vq,

/* When we start there are none of either input nor output. */

+ /* If this is an indirect entry, then this buffer contains a descriptor

+ * table which we handle as if it's any normal descriptor chain. */

- iov[*out_num + *in_num].iov_len = vq->vring.desc[i].len;

/* If this is an input descriptor, increment that count. */

@@ -697,11 +664,10 @@ static unsigned get_vq_desc(struct virtqueue *vq,

/* If we've got too many, that implies a descriptor loop. */

@@ -719,44 +685,20 @@ static void add_used(struct virtqueue *vq, unsigned int head, int len)

/* Make sure buffer is written before we update index. */

-/* This actually sends the interrupt for this virtqueue */

- /* If they don't want an interrupt, don't send one, unless empty. */

- if ((vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT)

- /* Send the Guest an interrupt tell them we used something up. */

-static void add_used_and_trigger(int fd, struct virtqueue *vq,

+static void add_used_and_trigger(struct virtqueue *vq, unsigned head, int len)

- * Here is the input terminal setting we save, and the routine to restore them

-/* We associate some data with the console for our exit hack. */

+ * We associate some data with the console for our exit hack. */

/* This is the routine which handles console input (ie. stdin). */

-static bool handle_console_input(int fd, struct device *dev)

- /* First we need a console buffer from the Guests's input virtqueue. */

- /* If they're not ready for input, stop listening to this file

- * descriptor. We'll start again once they add an input buffer. */

- /* This is why we convert to iovecs: the readv() call uses them, and so

- /* This implies that the console is closed, is /dev/null, or

- /* Remove callback from input vq, so it doesn't restart us. */

+ /* For simplicity, dying threads kill the whole Launcher. So

- * This is such a hack, but works surprisingly well. Each ^C has to be

- * in a buffer by itself, so they can't be too fast. But we check that

- * we get three within about a second, so they can't be too slow. */

+ * This is such a hack, but works surprisingly well. Each ^C has to

+ * be in a buffer by itself, so they can't be too fast. But we check

+ * that we get three within about a second, so they can't be too

+ /* Kill all Launcher processes with SIGINT, like normal ^C */

-/* Handling output for console is simple: we just get all the output buffers

-static void handle_console_output(int fd, struct virtqueue *vq, bool timeout)

+/* This is the routine which handles console output (ie. stdout). */

- /* Keep getting output buffers from the Guest until we run out. */

- while ((head = get_vq_desc(vq, iov, &out, &in)) != vq->vring.num) {

-/* This is called when we no longer want to hear about Guest changes to a

- * virtqueue. This is more efficient in high-traffic cases, but it means we

- * have to set a timer to check if any more changes have occurred. */

* Handling output for network is also simple: we get all the output buffers

- * and write them (ignoring the first element) to this device's file descriptor

-static void handle_net_output(int fd, struct virtqueue *vq, bool timeout)

- /* Keep getting output buffers from the Guest until we run out. */

- while ((head = get_vq_desc(vq, iov, &out, &in)) != vq->vring.num) {

- /* Block further kicks and set up a timer if we saw anything. */

- /* We never quite know how long should we wait before we check the

- * queue again for more packets. We start at 500 microseconds, and if

- * we get fewer packets than last time, we assume we made the timeout

- * too small and increase it by 10 microseconds. Otherwise, we drop it

- * by one microsecond every time. It seems to work well enough. */

-/* This is where we handle a packet coming in from the tun device to our

+/* This is where we handle packets coming in from the tun device to our

-static bool handle_tun_input(int fd, struct device *dev)

- /* First we need a network buffer from the Guests's recv virtqueue. */

- /* Now, it's expected that if we try to send a packet too

- * early, the Guest won't be ready yet. Wait until the device

- /* Now tell it we want to know if new things appear. */

- /* We'll turn this back on if input buffers are registered. */

- /* Read the packet from the device directly into the Guest's buffer. */

- verbose("tun input packet len %i [%02x %02x] (%s)\n", len,

- ((u8 *)iov[1].iov_base)[0], ((u8 *)iov[1].iov_base)[1],

+ /* Deliver interrupt now, since we're about to sleep. */

-/*L:215 This is the callback attached to the network and console input

- * virtqueues: it ensures we try again, in case we stopped console or net

-static void enable_fd(int fd, struct virtqueue *vq, bool timeout)

-static void net_enable_fd(int fd, struct virtqueue *vq, bool timeout)

+/* When a child dies, we kill our entire process group with SIGTERM. This

+ * also has the side effect that the shell restores the console for us! */

- /* We don't need to know again when Guest refills receive buffer. */

-/* When the Guest tells us they updated the status field, we handle it. */

- memset(get_feature_bits(dev) + dev->desc->feature_len, 0,

+ memset(get_feature_bits(dev) + dev->feature_len, 0, dev->feature_len);

+ /* We're going to be explicitly killing threads, so ignore them. */

+ /* Zero out the virtqueues, get rid of their threads */

- } else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) {

+ /* Create stack for thread and run it. Since stack grows

+ * upwards, we point the stack pointer to the end of this

+ /* CLONE_VM: because it has to access the Guest memory, and

+ vq->thread = clone(do_thread, stack + 32768, CLONE_VM | SIGCHLD, vq);

+ /* If we saved off the original terminal settings, restore them now. */

+/* When the Guest tells us they updated the status field, we handle it. */

+ /* A zero status is a reset, otherwise it's a set of flags. */

} else if (dev->desc->status & VIRTIO_CONFIG_S_DRIVER_OK) {

/* This is the generic routine we call when the Guest uses LHCALL_NOTIFY. */

/* Notifications to device descriptors update device status. */

- /* Notifications to virtqueues mean output has occurred. */

+ /* Devices *can* be used before status is set to DRIVER_OK. */

@@ -1049,71 +990,6 @@ static void handle_output(int fd, unsigned long addr)

- /* Check each device and virtqueue: flush blocked ones. */

-/* This is called when the Waker wakes us up: check for incoming file

- /* select() wants a zeroed timeval to mean "don't wait". */

- num = select(devices.max_infd+1, &fds, NULL, NULL, &poll);

- /* Otherwise, call the device(s) which have readable file

/* This routine allocates a new "struct lguest_device_desc" from descriptor

@@ -1159,7 +1035,7 @@ static struct lguest_device_desc *new_dev_desc(u16 type)

/* Each device descriptor is followed by the description of its virtqueues. We

* specify how many descriptors the virtqueue is to have. */

static void add_virtqueue(struct device *dev, unsigned int num_descs,

@@ -1174,8 +1050,8 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,

@@ -1191,6 +1067,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,

assert(dev->desc->config_len == 0 && dev->desc->feature_len == 0);

memcpy(device_config(dev), &vq->config, sizeof(vq->config));

@@ -1199,15 +1076,6 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,

- /* Set the routine to call when the Guest does something to this

- /* As an optimization, set the advisory "Don't Notify Me" flag if we

/* The first half of the feature bitmask is for us to advertise features. The

@@ -1219,7 +1087,7 @@ static void add_feature(struct device *dev, unsigned bit)

/* We can't extend the feature bits once we've added config bytes */

+ dev->feature_len = dev->desc->feature_len = (bit/CHAR_BIT) + 1;

@@ -1243,22 +1111,17 @@ static void set_config(struct device *dev, unsigned len, const void *conf)

* calling new_dev_desc() to allocate the descriptor and device memory.

-static struct device *new_device(const char *name, u16 type, int fd,

+static struct device *new_device(const char *name, u16 type)

- /* If we have an input handler for this file descriptor, then we add it

/* Append to device list. Prepending to a single-linked list is

* easier, but the user expects the devices to be arranged on the bus

- /* If we exit gracefully, the original settings will be

/* We store the console state in dev->priv, and initialize it. */

* they put something the input queue, we make sure we're listening to

* stdin. When they put something in the output queue, we write it to

- add_virtqueue(dev, VIRTQUEUE_NUM, handle_console_output);

/*M:010 Inter-guest networking is an interesting area. Simplest is to have a

* --sharenet=<name> option which opens or creates a named pipe. This can be

@@ -1447,21 +1289,23 @@ static int get_tun_device(char tapif[IFNAMSIZ])

- dev = new_device("net", VIRTIO_ID_NET, netfd, handle_tun_input);

/* Network devices need a receive and a send queue, just like

/* We need a socket to perform the magic network ioctls to bring up the

* tap interface, connect to the bridge etc. Any socket will do! */

@@ -1502,6 +1346,8 @@ static void setup_tun_net(char *arg)

* Remember that the block device is handled by a separate I/O thread. We head

- /* See if there's a request waiting. If not, nothing to do. */

/* Every block request should contain at least one output buffer

* (detailing the location on disk and the type of request) and one

@@ -1637,83 +1481,21 @@ static bool service_io(struct device *dev)

- /* We can't trigger an IRQ, because we're not the Launcher. It does

-/* This is the thread which actually services the I/O. */

- /* Close other side of workpipe so we get 0 read when main dies. */

- /* When this read fails, it means Launcher died, so we follow. */

- /* We acknowledge each request immediately to reduce latency,

- * rather than waiting until we've done them all. I haven't

- * That would be an interesting test, wouldn't it? You could

-/* Now we've seen the I/O thread, we return to the Launcher to see what happens

- * when that thread tells us it's completed some I/O. */

-static bool handle_io_finish(int fd, struct device *dev)

- /* If the I/O thread died, presumably it printed the error, so we

-/* When the Guest submits some I/O, we just need to wake the I/O thread. */

-static void handle_virtblk_output(int fd, struct virtqueue *vq, bool timeout)

- /* This is the pipe the I/O thread will use to tell us I/O is done. */

- dev = new_device("block", VIRTIO_ID_BLOCK, p[0], handle_io_finish);

/* The device has one virtqueue, where the Guest places requests. */

- add_virtqueue(dev, VIRTQUEUE_NUM, handle_virtblk_output);

@@ -1735,49 +1517,29 @@ static void setup_block_file(const char *filename)

- /* The I/O thread writes to this end of the pipe when done. */

- /* This is the second pipe, which is how we tell the I/O thread about

- /* Create stack for thread and run it. Since stack grows upwards, we

- * point the stack pointer to the end of this region. */

- /* SIGCHLD - We dont "wait" for our cloned thread, so prevent it from

- if (clone(io_thread, stack + 32768, CLONE_VM | SIGCHLD, dev) == -1)

- /* We don't need to keep the I/O thread's end of the pipes open. */

/* Our random number generator device reads from /dev/random into the Guest's

* input buffers. The usual case is that the Guest doesn't want random numbers

* and so has no buffers although /dev/random is still readable, whereas

-static bool handle_rng_input(int fd, struct device *dev)

/* First we need a buffer from the Guests's virtqueue. */

- /* If they're not ready for input, stop listening to this file

- * descriptor. We'll start again once they add an input buffer. */

@@ -1785,7 +1547,7 @@ static bool handle_rng_input(int fd, struct device *dev)

* it reads straight into the Guest's buffer. We loop to make sure we

@@ -1793,25 +1555,23 @@ static bool handle_rng_input(int fd, struct device *dev)

/* And this creates a "hardware" random number device for the Guest. */

- dev = new_device("rng", VIRTIO_ID_RNG, fd, handle_rng_input);

/* The device has one virtqueue, where the Guest places inbufs. */

@@ -1827,17 +1587,18 @@ static void __attribute__((noreturn)) restart_guest(void)

- /* The exec automatically gets rid of the I/O and Waker threads. */

/*L:220 Finally we reach the core of the Launcher which runs the Guest, serves

-static void __attribute__((noreturn)) run_guest(int lguest_fd)

@@ -1848,8 +1609,7 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd)

@@ -1858,19 +1618,9 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd)

+ /* Anything else means a bug or incompatible change. */

- /* Service input, then unset the BREAK to release the Waker. */

/* Memory, top-level pagetable, code startpoint and size of the

- /* Two temporaries and the /dev/lguest file descriptor. */

/* Save the args: we "reboot" by execing ourselves again. */

- /* We don't "wait" for the children, so prevent them from becoming

- /* First we initialize the device list. Since console and network

- * device receive input from a file descriptor, we keep an fdset

- * (infds) and the maximum fd number (max_infd) with the head of the

- * list. We also keep a pointer to the last device. Finally, we keep

- * the next interrupt number to use for devices (1: remember that 0 is

+ /* First we initialize the device list. We keep a pointer to the last

+ * device, and the next interrupt number to use for devices (1:

- /* We can timeout waiting for Guest network transmit. */

start = load_kernel(open_or_die(argv[optind+1], O_RDONLY));

/* We tell the kernel to initialize the Guest: this returns the open

- /* We clone off a thread, which wakes the Launcher whenever one of the

- * input file descriptors needs attention. We call this the Waker, and

+ /* If we exit via err(), this kills all the threads, restores tty. */

diff --git a/Documentation/lguest/lguest.txt b/Documentation/lguest/lguest.txt
index 28c747362f95..efb3a6a045a2 100644
--- a/Documentation/lguest/lguest.txt
+++ b/Documentation/lguest/lguest.txt

"Alignment value to which kernel should be aligned" = 0x100000

(CONFIG_PARAVIRT=y, CONFIG_LGUEST_GUEST=y, CONFIG_HIGHMEM64G=n and

diff --git a/Documentation/local_ops.txt b/Documentation/local_ops.txt
index 23045b8b50f0..300da4bdfdbd 100644
--- a/Documentation/local_ops.txt
+++ b/Documentation/local_ops.txt

@@ -34,7 +34,7 @@ out of order wrt other memory writes by the owner CPU.

It can be done by slightly modifying the standard atomic operations : only

their UP variant must be kept. It typically means removing LOCK prefix (on

-i386 and x86_64) and any SMP sychronization barrier. If the architecture does

+i386 and x86_64) and any SMP synchronization barrier. If the architecture does

not have a different behavior between SMP and UP, including asm-generic/local.h

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index f5b7127f54ac..7f5809eddee6 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt

@@ -1217,6 +1218,132 @@ barriers are required in such a situation, they must be provided from some

+Sleeping and waking on an event flagged in global data can be viewed as an

+interaction between two pieces of data: the task state of the task waiting for

+the event and the global data used to indicate the event. To make sure that

+these appear to happen in the right order, the primitives to begin the process

+of going to sleep, and the primitives to initiate a wake up imply certain

+Firstly, the sleeper normally follows something like this sequence of events:

+A general memory barrier is interpolated automatically by set_current_state()

+which therefore also imply a general memory barrier after setting the state.

+The whole sequence above is available in various canned forms, all of which

+Secondly, code that performs a wake up normally follows something like this:

+A write memory barrier is implied by wake_up() and co. if and only if they wake

+something up. The barrier occurs before the task state is cleared, and so sits

+between the STORE to indicate the event and the STORE to set TASK_RUNNING:

+ =============================== ===============================

+[!] Note that the memory barriers implied by the sleeper and the waker do _not_

+order multiple stores before the wake-up with respect to loads of those stored

+values after the sleeper has called set_current_state(). For instance, if the

+there's no guarantee that the change to event_indicated will be perceived by

+the sleeper as coming after the change to my_data. In such a circumstance, the

+code on both sides must interpolate its own memory barriers between the

+separate data accesses. Thus the above sleeper ought to do:

Under normal operation, memory operation reordering is generally not going to

be a problem as a single-threaded linear piece of code will still appear to

-work correctly, even if it's in an SMP kernel. There are, however, three

+work correctly, even if it's in an SMP kernel. There are, however, four

circumstances in which reordering definitely _could_ be a problem:

diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 4c2ecf537a4a..bbc8a6a36921 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt

@@ -73,13 +73,13 @@ this phase is triggered automatically. ACPI can notify this event. If not,

Logical Memory Hotplug phase is to change memory state into

-avaiable/unavailable for users. Amount of memory from user's view is

+available/unavailable for users. Amount of memory from user's view is

changed by this phase. The kernel makes all memory in it as free pages

In this document, this phase is described as online/offline.

-Logical Memory Hotplug phase is triggred by write of sysfs file by system

+Logical Memory Hotplug phase is triggered by write of sysfs file by system

administrator. For the hot-add case, it must be executed after Physical Hotplug

(However, if you writes udev's hotplug scripts for memory hotplug, these

- Generated when memory has succesfully brought online. The callback may

+ Generated when memory has successfully brought online. The callback may

@@ -359,7 +359,7 @@ The third argument is passed by pointer of struct memory_notify.

diff --git a/Documentation/mn10300/ABI.txt b/Documentation/mn10300/ABI.txt
index 1fef1f06dfd2..d3507bad428d 100644
--- a/Documentation/mn10300/ABI.txt
+++ b/Documentation/mn10300/ABI.txt

@@ -26,7 +26,7 @@ registers and the stack. If the first argument is a 64-bit value, it will be

passed in D0:D1. If the first argument is not a 64-bit value, but the second

is, the second will be passed entirely on the stack and D1 will be unused.

-Arguments smaller than 32-bits are not coelesced within a register or a stack

+Arguments smaller than 32-bits are not coalesced within a register or a stack

word. For example, two byte-sized arguments will always be passed in separate

diff --git a/Documentation/mtd/nand_ecc.txt b/Documentation/mtd/nand_ecc.txt
index bdf93b7f0f24..274821b35a7f 100644
--- a/Documentation/mtd/nand_ecc.txt
+++ b/Documentation/mtd/nand_ecc.txt

@@ -50,7 +50,7 @@ byte 255: bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0 rp1 rp3 rp5 ... rp15

-cp is my abbreviaton for column parity, rp for row parity.

+cp is my abbreviation for column parity, rp for row parity.

cp0 is the parity that belongs to all bit0, bit2, bit4, bit6.

@@ -560,7 +560,7 @@ Measuring this code again showed big gain. When executing the original

linux code 1 million times, this took about 1 second on my system.

(using time to measure the performance). After this iteration I was back

to 0.075 sec. Actually I had to decide to start measuring over 10

-million interations in order not to loose too much accuracy. This one

+million iterations in order not to lose too much accuracy. This one

There is a little bit more room for improvement though. There are three

@@ -571,8 +571,8 @@ loop; This eliminates 3 statements per loop. Of course after the loop we

-Furthermore there are 4 sequential assingments to rp8. This can be

-encoded slightly more efficient by saving tmppar before those 4 lines

+Furthermore there are 4 sequential assignments to rp8. This can be

+encoded slightly more efficiently by saving tmppar before those 4 lines

@@ -622,7 +622,7 @@ Not a big change, but every penny counts :-)

-Acutally this made things worse. Not very much, but I don't want to move

+Actually this made things worse. Not very much, but I don't want to move

into the wrong direction. Maybe something to investigate later. Could

This makes things worse. Let's stick with attempt 6 and continue from there.

Although it seems that the code within the loop cannot be optimised

further there is still room to optimize the generation of the ecc codes.

-We can simply calcualate the total parity. If this is 0 then rp4 = rp5

+We can simply calculate the total parity. If this is 0 then rp4 = rp5

But if rp4 = rp5 we do not need rp5 etc. We can just write the even bits

diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 08762750f121..d5181ce9ff62 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt

generally referred to as "trunk failover." This is a feature of the

switch that causes the link state of a particular switch port to be set

down (or up) when the state of another switch port goes down (or up).

-It's purpose is to propogate link failures from logically "exterior" ports

+Its purpose is to propagate link failures from logically "exterior" ports

to the logically "interior" ports that bonding is able to monitor via

miimon. Availability and configuration for trunk failover varies by

switch, but this can be a viable alternative to the ARP monitor when using

diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index 2035bc4932f2..cd79735013f9 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt

============================================================================

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

removal of vcan network devices can be managed with the ip(8) tool:

- Create a virtual CAN network interface with a specific name 'vcan42':

- The tool 'vcan' from the SocketCAN SVN repository on BerliOS is obsolete.

- In Linux Kernel versions < 2.6.24 the vcan driver creates 4 vcan

- netdevices at module load time by default. This value can be changed

- with the module parameter 'numdev'. E.g. 'modprobe vcan numdev=8'

+ The CAN network device driver interface provides a generic interface

+ to setup, configure and monitor CAN network devices. The user can then

+ configure the CAN device, like setting the bit-timing parameters, via

+ the netlink interface using the program "ip" from the "IPROUTE2"

+ utility suite. The following chapter describes briefly how to use it.

+ Furthermore, the interface uses a common data structure and exports a

+ set of common functions, which all real CAN network device drivers

+ should use. Please have a look to the SJA1000 or MSCAN driver to

+ understand how to use them. The name of the module is can-dev.ko.

+ The CAN device must be configured via netlink interface. The supported

+ netlink message types are defined and briefly described in

+ "include/linux/can/netlink.h". CAN link support for the program "ip"

+ of the IPROUTE2 utility suite is avaiable and it can be used as shown

+ 2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP qlen 10

+ can <TRIPLE-SAMPLING> state ERROR-ACTIVE restart-ms 100

+ sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1

+ re-started bus-errors arbit-lost error-warn error-pass bus-off

+ Shows the list of selected CAN controller modes: LOOPBACK,

+ The current state of the CAN controller: "ERROR-ACTIVE",

+ "ERROR-WARNING", "ERROR-PASSIVE", "BUS-OFF" or "STOPPED"

+ Automatic restart delay time. If set to a non-zero value, a

+ restart of the CAN controller will be triggered automatically

+ in case of a bus-off condition after the specified delay time

+ Shows the real bit-rate in bits/sec and the sample-point in the

+ range 0.000..0.999. If the calculation of bit-timing parameters

+ is enabled in the kernel (CONFIG_CAN_CALC_BITTIMING=y), the

+ bit-timing can be defined by setting the "bitrate" argument.

+ Optionally the "sample-point" can be specified. By default it's

+ Shows the time quanta in ns, propagation segment, phase buffer

+ segment 1 and 2 and the synchronisation jump width in units of

+ tq. They allow to define the CAN bit-timing in a hardware

+ independent format as proposed by the Bosch CAN 2.0 spec (see

+ chapter 8 of http://www.semiconductors.bosch.de/pdf/can2spec.pdf).

+ "sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1

+ Shows the bit-timing constants of the CAN controller, here the

+ "sja1000". The minimum and maximum values of the time segment 1

+ and 2, the synchronisation jump width in units of tq, the

+ bitrate pre-scaler and the CAN system clock frequency in Hz.

+ These constants could be used for user-defined (non-standard)

+ "re-started bus-errors arbit-lost error-warn error-pass bus-off"

+ Shows the number of restarts, bus and arbitration lost errors,

+ and the state changes to the error-warning, error-passive and

+ bus-off state. RX overrun errors are listed in the "overrun"

+ The CAN bit-timing parameters can always be defined in a hardware

+ independent format as proposed in the Bosch CAN 2.0 specification

+ specifying the arguments "tq", "prop_seg", "phase_seg1", "phase_seg2"

+ If the kernel option CONFIG_CAN_CALC_BITTIMING is enabled, CIA

+ recommended CAN bit-timing parameters will be calculated if the bit-

+ Note that this works fine for the most common CAN controllers with

+ standard bit-rates but may *fail* for exotic bit-rates or CAN system

+ clock frequencies. Disabling CONFIG_CAN_CALC_BITTIMING saves some

+ space and allows user-space tools to solely determine and set the

+ bit-timing parameters. The CAN controller specific bit-timing

+ constants can be used for that purpose. They are listed by the

+ sja1000: clock 8000000 tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1

+ A CAN network device is started or stopped as usual with the command

+ "ifconfig canX up/down" or "ip link set canX up/down". Be aware that

+ you *must* define proper bit-timing parameters for real CAN devices

+ before you can start it to avoid error-prone default settings:

+ A device may enter the "bus-off" state if too much errors occurred on

+ the CAN bus. Then no more messages are received or sent. An automatic

+ bus-off recovery can be enabled by setting the "restart-ms" to a

+ Alternatively, the application may realize the "bus-off" condition

+ by monitoring CAN error frames and do a restart when appropriate with

+ Note that a restart will also create a CAN error frame (see also

- On the project website http://developer.berlios.de/projects/socketcan

- vcan: Virtual CAN interface driver (if no real hardware is available)

- mscan: Motorola/Freescale CAN controller (e.g. inside SOC MPC5200)

- slcan: For a bunch of CAN adaptors that are attached via a

+ Please check the "Kconfig" file in "drivers/net/can" to get an actual

+ list of the support CAN hardware. On the Socket CAN project website

+ (see chapter 7) there might be further drivers available, also for

- Additionally the different CAN adaptors (ISA/PCI/PCMCIA/USB/Parport)

- from PEAK Systemtechnik support the CAN netdevice driver model

- since Linux driver v6.0: http://www.peak-system.com/linux/index.htm

- Please check the Mailing Lists on the berlios OSS project website.

+ You can find further resources for Socket CAN like user space tools,

+ support for old kernel versions, more drivers, mailing lists, etc.

- The configuration interface for CAN network drivers is still an open

- issue that has not been finalized in the socketcan project. Also the

- idea of having a library module (candev.ko) that holds functions

- that are needed by all CAN netdevices is not ready to ship.

+ If you have questions, bug fixes, etc., don't hesitate to post them to

+ the Socketcan-Users mailing list. But please search the archives first.

+ Oliver Hartkopp (PF_CAN core, filters, drivers, bcm, SJA1000 driver)

Urs Thuermann (PF_CAN core, kernel integration, socket interfaces, raw, vcan)

- Wolfgang Grandegger (RT-SocketCAN core & drivers, Raw Socket-API reviews)

+ Wolfgang Grandegger (RT-SocketCAN core & drivers, Raw Socket-API reviews,

Marc Kleine-Budde (design reviews, Kernel 2.6 cleanups, drivers)

Thomas Gleixner (LKML reviews, coding style, posting hints)

- Andrey Volkov (kernel subtree structure, ioctls, mscan driver)

+ Andrey Volkov (kernel subtree structure, ioctls, MSCAN driver)

Matthias Brukner (first SJA1000 CAN netdevice implementation Q2/2003)

Michael Schulze (driver layer loopback requirement, RT CAN drivers review)

diff --git a/Documentation/networking/dm9000.txt b/Documentation/networking/dm9000.txt
index 65df3dea5561..5552e2e575c5 100644
--- a/Documentation/networking/dm9000.txt
+++ b/Documentation/networking/dm9000.txt

The driver keeps track of the link state and informs the network core

-about link (carrier) availablilty. This is managed by several methods

+about link (carrier) availability. This is managed by several methods

depending on the version of the chip and on which PHY is being used.

For the internal PHY, the original (and currently default) method is

diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
new file mode 100644
index 000000000000..a0280ad2edc9
--- /dev/null
+++ b/Documentation/networking/ieee802154.txt

+The Linux-ZigBee project goal is to provide complete implementation

+of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack

+of protocols for organizing Low-Rate Wireless Personal Area Networks.

+Currently only IEEE 802.15.4 layer is implemented. We have choosen

+to use plain Berkeley socket API, the generic Linux networking stack

+to transfer IEEE 802.15.4 messages and a special protocol over genetlink

+The address family, socket addresses etc. are defined in the

+include/net/ieee802154/af_ieee802154.h header or in the special header

+in our userspace package (see either linux-zigbee sourceforge download page

+or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee).

+One can use SOCK_RAW for passing raw data towards device xmit function. YMMV.

+Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands.

+See the include/net/ieee802154/nl802154.h header. Our userspace tools package

+(see above) provides CLI configuration utility for radio interfaces and simple

+coordinator for IEEE 802.15.4 networks as an example users of MLME protocol.

+Like with WiFi, there are several types of devices implementing IEEE 802.15.4.

+1) 'HardMAC'. The MAC layer is implemented in the device itself, the device

+2) 'SoftMAC' or just radio. These types of devices are just radio transceivers

+ possibly with some kinds of acceleration like automatic CRC computation and

+ comparation, automagic ACK handling, address matching, etc.

+Those types of devices require different approach to be hooked into Linux kernel.

+See the header include/net/ieee802154/netdevice.h. You have to implement Linux

+net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family

+code via plain sk_buffs. The control block of sk_buffs will contain additional

+To hook the MLME interface you have to populate the ml_priv field of your

+net_device with a pointer to struct ieee802154_mlme_ops instance. All fields are

+We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c

+We are going to provide intermediate layer impelementing IEEE 802.15.4 MAC

+See header include/net/ieee802154/mac802154.h and several drivers in

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index ec5de02f543f..8be76235fe67 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt

+ Enable Explicit Congestion Notification (ECN) in TCP. ECN is only

+ used when both ends of the TCP flow support it. It is useful to

+ avoid losses due to congestion (when the bottleneck router supports

Enable FACK congestion avoidance and fast retransmission.

+ When this value is changed from 1 to 0 (IPv6 is being enabled),

+ it will dynamically create a link-local address on the given

+ interface and start Duplicate Address Detection, if necessary.

+ When this value is changed from 0 to 1 (IPv6 is being disabled),

+ it will dynamically delete all address on the given interface.

@@ -1266,13 +1282,22 @@ sctp_rmem - vector of 3 INTEGERs: min, default, max

+ The maximum number of packets that kernel can handle on a NAPI

diff --git a/Documentation/networking/ipv6.txt b/Documentation/networking/ipv6.txt
index 268e5c103dd8..9fd7e21296c8 100644
--- a/Documentation/networking/ipv6.txt
+++ b/Documentation/networking/ipv6.txt

+ Specifies whether to enable IPv6 address autoconfiguration

+ on all interfaces. This might be used when one does not wish

+ for addresses to be automatically generated from prefixes

+ IPv6 address autoconfiguration is disabled on all interfaces.

+ Only the IPv6 loopback address (::1) and link-local addresses

+ IPv6 address autoconfiguration is enabled on all interfaces.

diff --git a/Documentation/networking/l2tp.txt b/Documentation/networking/l2tp.txt
index 2451f551c505..63214b280e00 100644
--- a/Documentation/networking/l2tp.txt
+++ b/Documentation/networking/l2tp.txt

The PPPoL2TP driver was developed as part of the OpenL2TP project by

diff --git a/Documentation/networking/mac80211-injection.txt b/Documentation/networking/mac80211-injection.txt
index 84906ef3ed6e..b30e81ad5307 100644
--- a/Documentation/networking/mac80211-injection.txt
+++ b/Documentation/networking/mac80211-injection.txt

-Despite 13 radiotap argument types are currently defined, most only make sense

+Despite many radiotap parameters being currently defined, most only make sense

to appear on received packets. The following information is parsed from the

- rate in 500kbps units, automatic if invalid or not present

IEEE80211_RADIOTAP_F_FCS: FCS will be removed and recalculated

IEEE80211_RADIOTAP_F_WEP: frame will be encrypted if key available

IEEE80211_RADIOTAP_F_FRAG: frame will be fragmented if longer than the

The injection code can also skip all other currently defined radiotap fields

facilitating replay of captured radiotap headers directly.

-Here is an example valid radiotap header defining these three parameters

+Here is an example valid radiotap header defining some parameters

-You can also find sources for a complete inject test applet here:

+You can also find a link to a complete inject application here:

-http://penumbra.warmcat.com/_twk/tiki-index.php?page=packetspammer

+http://wireless.kernel.org/en/users/Documentation/packetspammer

diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt
index a2ab6a0b116d..87b3d15f523a 100644
--- a/Documentation/networking/netdevices.txt
+++ b/Documentation/networking/netdevices.txt

for this and return NETDEV_TX_LOCKED when the spin lock fails.

set_multicast_list. Note that the use of NETIF_F_LLTX is deprecated.

diff --git a/Documentation/networking/operstates.txt b/Documentation/networking/operstates.txt
index c9074f9b78bb..1a77a3cfae54 100644
--- a/Documentation/networking/operstates.txt
+++ b/Documentation/networking/operstates.txt

-These interface flags can also be queried without netlink using the

contains RFC2863 state of the interface in numeric representation:

diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 07c53d596035..a22fd85e3796 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt

This file documents the CONFIG_PACKET_MMAP option available with the PACKET

socket interface on 2.4 and 2.6 kernels. This type of sockets is used for

-capture network traffic with utilities like tcpdump or any other that uses

+capture network traffic with utilities like tcpdump or any other that needs

-------------------------------------------------------------------------------

@@ -25,19 +27,24 @@ to capture each packet, it requires two if you want to get packet's

In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size

-configurable circular buffer mapped in user space. This way reading packets just

-needs to wait for them, most of the time there is no need to issue a single

-system call. By using a shared buffer between the kernel and the user

-It's fine to use PACKET_MMAP to improve the performance of the capture process,

-but it isn't everything. At least, if you are capturing at high speeds (this

-is relative to the cpu speed), you should check if the device driver of your

-network interface card supports some sort of interrupt load mitigation or

-(even better) if it supports NAPI, also make sure it is enabled.

+configurable circular buffer mapped in user space that can be used to either

+send or receive packets. This way reading packets just needs to wait for them,

+most of the time there is no need to issue a single system call. Concerning

+transmission, multiple packets can be sent through one system call to get the

+By using a shared buffer between the kernel and the user also has the benefit

+It's fine to use PACKET_MMAP to improve the performance of the capture and

+transmission process, but it isn't everything. At least, if you are capturing

+at high speeds (this is relative to the cpu speed), you should check if the

+device driver of your network interface card supports some sort of interrupt

+load mitigation or (even better) if it supports NAPI, also make sure it is

+enabled. For transmission, check the MTU (Maximum Transmission Unit) used and

--------------------------------------------------------------------------------

++ How to use CONFIG_PACKET_MMAP to improve capture process

--------------------------------------------------------------------------------

From the user standpoint, you should use the higher level libpcap library, which

@@ -57,7 +64,7 @@ the low level details or want to improve libpcap by including PACKET_MMAP

--------------------------------------------------------------------------------

++ How to use CONFIG_PACKET_MMAP directly to improve capture process

--------------------------------------------------------------------------------

From the system calls stand point, the use of PACKET_MMAP involves

setsockopt() ---> allocation of the circular buffer (ring)

@@ -97,13 +105,75 @@ also the mapping of the circular buffer in the user process and

--------------------------------------------------------------------------------

++ How to use CONFIG_PACKET_MMAP directly to improve transmission process

+--------------------------------------------------------------------------------

+Transmission process is similar to capture as shown below.

+[setup] socket() -------> creation of the transmission socket

+ setsockopt() ---> allocation of the circular buffer (ring)

+ bind() ---------> bind transmission socket with a network interface

+ mmap() ---------> mapping of the allocated buffer to the

+[transmission] poll() ---------> wait for free packets (optional)

+ send() ---------> send all packets that are set as ready in

+[shutdown] close() --------> destruction of the transmission socket and

+Binding the socket to your network interface is mandatory (with zero copy) to

+know the header size of frames used in the circular buffer.

+| struct tpacket_hdr | Header. It contains the status of

+ bind() associates the socket to your network interface thanks to

+ strncpy (s_ifr.ifr_name, "eth0", sizeof(s_ifr.ifr_name));

+ bind(this->socket, (struct sockaddr *)&my_addr, sizeof(struct sockaddr_ll));

+ A complete tutorial is available at: http://wiki.gnu-log.net/

+--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

To setup PACKET_MMAP from user level code is done with a call like

setsockopt(fd, SOL_PACKET, PACKET_RX_RING, (void *) &req, sizeof(req))

+ setsockopt(fd, SOL_PACKET, PACKET_TX_RING, (void *) &req, sizeof(req))

The most significant argument in the previous call is the req parameter,

@@ -117,11 +187,11 @@ this parameter must to have the following structure:

This structure is defined in /usr/include/linux/if_packet.h and establishes a

-circular buffer (ring) of unswappable memory mapped in the capture process.

Being mapped in the capture process allows reading the captured frames and

related meta-information like timestamps without requiring a system call.

-Captured frames are grouped in blocks. Each block is a physically contiguous

+Frames are grouped in blocks. Each block is a physically contiguous

region of memory and holds tp_block_size/tp_frame_size frames. The total number

of blocks is tp_block_nr. Note that tp_frame_nr is a redundant parameter because

@@ -336,6 +406,7 @@ struct tpacket_hdr). If this field is 0 means that the frame is ready

to be used for the kernel, If not, there is a frame the user can read

It doesn't incur in a race condition to first check the status value and

+ #define TP_STATUS_SEND_REQUEST 1 // Frame will be sent on next send()

+ #define TP_STATUS_SENDING 2 // Frame is currently in transmission

+ #define TP_STATUS_WRONG_FORMAT 4 // Frame format is not correct

+First, the kernel initializes all frames to TP_STATUS_AVAILABLE. To send a

+packet, the user fills a data buffer of an available frame, sets tp_len to

+current data buffer size and sets its status field to TP_STATUS_SEND_REQUEST.

+This can be done on multiple frames. Once the user is ready to transmit, it

+calls send(). Then all buffers with status equal to TP_STATUS_SEND_REQUEST are

+forwarded to the network device. The kernel updates each status of sent

+frames with TP_STATUS_SENDING until the end of transfer.

+At the end of each transfer, buffer status returns to TP_STATUS_AVAILABLE.

+The user can also use poll() to check if a buffer is available:

--------------------------------------------------------------------------------

diff --git a/Documentation/networking/phonet.txt b/Documentation/networking/phonet.txt
index 6a07e45d4a93..6e8ce09f9c73 100644
--- a/Documentation/networking/phonet.txt
+++ b/Documentation/networking/phonet.txt

@@ -36,7 +36,7 @@ Phonet packets have a common header as follows:

On Linux, the link-layer header includes the pn_media byte (see below).

-The device ID is split: the 6 higher-order bits consitute the device

+The device ID is split: the 6 higher-order bits constitute the device

address, while the 2 lower-order bits are used for multiplexing, as are

the 8-bit object identifiers. As such, Phonet can be considered as a

network layer with 6 bits of address space and 10 bits for transport

diff --git a/Documentation/networking/regulatory.txt b/Documentation/networking/regulatory.txt
index dcf31648414a..eaa1a25946c1 100644
--- a/Documentation/networking/regulatory.txt
+++ b/Documentation/networking/regulatory.txt

@@ -89,7 +89,7 @@ added to this document when its support is enabled.

Device drivers who provide their own built regulatory domain

do not need a callback as the channels registered by them are

the only ones that will be allowed and therefore *additional*

diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 421e7d00ffd0..c9abbd86bc18 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt

@@ -75,9 +75,6 @@ may need to apply in domain-specific ways to their devices:

- int (*suspend_late)(struct device *dev, pm_message_t state);

@@ -226,20 +223,7 @@ The phases are seen by driver notifications issued in this order:

This call should handle parts of device suspend logic that require

sleeping. It probably does work to quiesce the device which hasn't

- been abstracted into class.suspend() or bus.suspend_late().

- 3 bus.suspend_late(dev, message) is called with IRQs disabled, and

- with only one CPU active. Until the bus.resume_early() phase

- completes (see later), IRQs are not enabled again. This method

- won't be exposed by all busses; for message based busses like USB,

- I2C, or SPI, device interactions normally require IRQs. This bus

- call may be morphed into a driver call with bus-specific parameters.

- This call might save low level hardware state that might otherwise

- be lost in the upcoming low power state, and actually put the

- device into a low power state ... so that in some cases the device

- may stay partly usable until this late. This "late" call may also

The pm_message_t parameter is currently used to refine those semantics

@@ -351,19 +335,11 @@ devices processing each phase's calls before the next phase begins.

The phases are seen by driver notifications issued in this order:

- 1 bus.resume_early(dev) is called with IRQs disabled, and with

- only one CPU active. As with bus.suspend_late(), this method

- won't be supported on busses that require IRQs in order to

- 2 bus.resume(dev) is called next. This may be morphed into a device

- driver call with bus-specific parameters; implementations may sleep.

+ 1 bus.resume(dev) reverses the effects of bus.suspend(). This may

+ be morphed into a device driver call with bus-specific parameters;

- 3 class.resume(dev) is called for devices associated with a class

+ 2 class.resume(dev) is called for devices associated with a class

This reverses the effects of class.suspend(), and would usually

diff --git a/Documentation/power/regulator/consumer.txt b/Documentation/power/regulator/consumer.txt
index 82b7a43aadba..5f83fd24ea84 100644
--- a/Documentation/power/regulator/consumer.txt
+++ b/Documentation/power/regulator/consumer.txt

@@ -178,5 +178,5 @@ Consumers can uregister interest by calling :-

int regulator_unregister_notifier(struct regulator *regulator,

-Regulators use the kernel notifier framework to send event to thier interested

+Regulators use the kernel notifier framework to send event to their interested

diff --git a/Documentation/power/regulator/overview.txt b/Documentation/power/regulator/overview.txt
index bdcb332bd7fb..0cded696ca01 100644
--- a/Documentation/power/regulator/overview.txt
+++ b/Documentation/power/regulator/overview.txt

- regulator operating parameters for input/ouput voltage.

+ regulator operating parameters for input/output voltage.

diff --git a/Documentation/power/s2ram.txt b/Documentation/power/s2ram.txt
index 2ebdc6091ce1..514b94fc931e 100644
--- a/Documentation/power/s2ram.txt
+++ b/Documentation/power/s2ram.txt

@@ -63,7 +63,7 @@ hardware during resume operations where a value can be set that will

Consequence is that after a resume (even if it is successful) your system

-clock will have a value corresponding to the magic mumber instead of the

+clock will have a value corresponding to the magic number instead of the

correct date/time! It is therefore advisable to use a program like ntp-date

or rdate to reset the correct date/time from an external time source when

diff --git a/Documentation/power/userland-swsusp.txt b/Documentation/power/userland-swsusp.txt
index 7b99636564c8..b967cd9137d6 100644
--- a/Documentation/power/userland-swsusp.txt
+++ b/Documentation/power/userland-swsusp.txt

@@ -109,7 +109,7 @@ unfreeze user space processes frozen by SNAPSHOT_UNFREEZE if they are

Currently it is assumed that the userland utilities reading/writing the

-snapshot image from/to the kernel will use a swap parition, called the resume

+snapshot image from/to the kernel will use a swap partition, called the resume

partition, or a swap file as storage space (if a swap file is used, the resume

partition is the partition that holds this file). However, this is not really

required, as they can use, for example, a special (blank) suspend partition or

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index d16b7a1c3793..8d999d862d0e 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt

@@ -1356,7 +1356,7 @@ platforms are moved over to use the flattened-device-tree model.

- phy-map : 1 cell, optional, bitmap of addresses to probe the PHY

- rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec

@@ -1438,7 +1438,7 @@ platforms are moved over to use the flattened-device-tree model.

The Xilinx EDK toolchain ships with a set of IP cores (devices) for use

in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range

- of standard device types (network, serial, etc.) and miscellanious

+ of standard device types (network, serial, etc.) and miscellaneous

devices (gpio, LCD, spi, etc). Also, since these devices are

implemented within the fpga fabric every instance of the device can be

synthesised with different options that change the behaviour.

diff --git a/Documentation/powerpc/dts-bindings/can/sja1000.txt b/Documentation/powerpc/dts-bindings/can/sja1000.txt
new file mode 100644
index 000000000000..d6d209ded937
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/can/sja1000.txt

+Memory mapped SJA1000 CAN controller from NXP (formerly Philips)

+- reg : should specify the chip select, address offset and size required

+ to map the registers of the SJA1000. The size is usually 0x80.

+- interrupts: property with a value describing the interrupt source

+- nxp,external-clock-frequency : Frequency of the external oscillator

+ clock in Hz. Note that the internal clock frequency used by the

+ SJA1000 is half of that value. If not specified, a default value

+- nxp,tx-output-mode : operation mode of the TX output control logic:

+- nxp,clock-out-frequency : clock frequency in Hz on the CLKOUT pin.

+ If not specified or if the specified value is 0, the CLKOUT pin

+- nxp,no-comparator-bypass : Allows to disable the CAN input comperator.

+For futher information, please have a look to the SJA1000 data sheet.

diff --git a/Documentation/powerpc/dts-bindings/ecm.txt b/Documentation/powerpc/dts-bindings/ecm.txt
new file mode 100644
index 000000000000..f514f29c67d6
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/ecm.txt

+=====================================================================

+The LAW node represents the region of CCSR space where local access

+windows are configured. For ECM based devices this is the first 4k

+of CCSR space that includes CCSRBAR, ALTCBAR, ALTCAR, BPTR, and some

+number of local access windows as specified by fsl,num-laws.

+ Definition: A standard property. The value specifies the

+ Definition: The value specifies the number of local access

+=====================================================================

+The E500 LAW node represents the region of CCSR space where ECM config

+and error reporting registers exist, this is the second 4k (0x1000)

+ Definition: Must include "fsl,CHIP-ecm", "fsl,ecm" where

+ Definition: A standard property. The value specifies the

+=====================================================================

diff --git a/Documentation/powerpc/dts-bindings/fsl/board.txt b/Documentation/powerpc/dts-bindings/fsl/board.txt
index 6c974d28eeb4..e8b5bc24d0ac 100644
--- a/Documentation/powerpc/dts-bindings/fsl/board.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/board.txt

- reg : Should contain the address and the length of the GPIO bank

- #gpio-cells : Should be two. The first cell is the pin number and the

- second cell is used to specify optional paramters (currently unused).

+ second cell is used to specify optional parameters (currently unused).

diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt
index 088fc471e03a..160c752484b4 100644
--- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt

- fsl,cpm-command : This value is ORed with the opcode and command flag

diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt
index 1815dfede1bc..349f79fd7076 100644
--- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt

- #gpio-cells : Should be two. The first cell is the pin number and the

- second cell is used to specify optional paramters (currently unused).

+ second cell is used to specify optional parameters (currently unused).

Example of three SOC GPIO banks defined as gpio-controller nodes:

diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
index 78790d58dc2c..6e37be1eeb2d 100644
--- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt

- model : precise model of the QE, Can be "QE", "CPM", or "CPM2"

+- fsl,qe-num-riscs: define how many RISC engines the QE has.

+- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the

- brg-frequency : the internal clock source frequency for baud-rate

diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
index 600846557763..5093ddf900da 100644
--- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt

@@ -5,8 +5,7 @@ for MMC, SD, and SDIO types of memory cards.

- "fsl,<chip>-esdhc", "fsl,mpc8379-esdhc" for MPC83xx processors.

- "fsl,<chip>-esdhc", "fsl,mpc8536-esdhc" for MPC85xx processors.

- reg : should contain eSDHC registers location and length.

diff --git a/Documentation/powerpc/dts-bindings/fsl/mcm.txt b/Documentation/powerpc/dts-bindings/fsl/mcm.txt
new file mode 100644
index 000000000000..4ceda9b3b413
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/mcm.txt

+=====================================================================

+The LAW node represents the region of CCSR space where local access

+windows are configured. For MCM based devices this is the first 4k

+of CCSR space that includes CCSRBAR, ALTCBAR, ALTCAR, BPTR, and some

+number of local access windows as specified by fsl,num-laws.

+ Definition: A standard property. The value specifies the

+ Definition: The value specifies the number of local access

+=====================================================================

+The MPX LAW node represents the region of CCSR space where MCM config

+and error reporting registers exist, this is the second 4k (0x1000)

+ Definition: Must include "fsl,CHIP-mcm", "fsl,mcm" where

+ Definition: A standard property. The value specifies the

+=====================================================================

diff --git a/Documentation/powerpc/dts-bindings/fsl/msi-pic.txt b/Documentation/powerpc/dts-bindings/fsl/msi-pic.txt
index b26b91992c55..bcc30bac6831 100644
--- a/Documentation/powerpc/dts-bindings/fsl/msi-pic.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/msi-pic.txt

first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572,

etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on

diff --git a/Documentation/powerpc/dts-bindings/fsl/pmc.txt b/Documentation/powerpc/dts-bindings/fsl/pmc.txt
index 02f6f43ee1b7..07256b7ffcaa 100644
--- a/Documentation/powerpc/dts-bindings/fsl/pmc.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/pmc.txt

compatible; all statements below that apply to "fsl,mpc8548-pmc" also

- Compatibility does not include bit assigments in SCCR/PMCDR/DEVDISR; these

- bit assigments are indicated via the sleep specifier in each device's

+ Compatibility does not include bit assignments in SCCR/PMCDR/DEVDISR; these

+ bit assignments are indicated via the sleep specifier in each device's

- reg: For devices compatible with "fsl,mpc8349-pmc", the first resource

diff --git a/Documentation/powerpc/qe_firmware.txt b/Documentation/powerpc/qe_firmware.txt
index 06da4d4b44f9..2031ddb33d09 100644
--- a/Documentation/powerpc/qe_firmware.txt
+++ b/Documentation/powerpc/qe_firmware.txt

@@ -225,7 +225,7 @@ For example, to match the 8323, revision 1.0:

-'padding' is neccessary for structure alignment. This field ensures that the

+'padding' is necessary for structure alignment. This field ensures that the

'extended_modes' is a bitfield that defines special functionality which has an

diff --git a/Documentation/rbtree.txt b/Documentation/rbtree.txt
index 7224459b469e..aae8355d3166 100644
--- a/Documentation/rbtree.txt
+++ b/Documentation/rbtree.txt

@@ -146,10 +146,10 @@ To remove an existing node from a tree, call:

for (node = rb_first(&mytree); node; node = rb_next(node))

+ printk("key=%s\n", rb_entry(node, struct mytype, node)->keystring);

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 4d3ee317a4a3..1b74b5f30af4 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt

-The rfkill switch subsystem exists to add a generic interface to circuitry that

-can enable or disable the signal output of a wireless *transmitter* of any

-type. By far, the most common use is to disable radio-frequency transmitters.

+The rfkill subsystem provides a generic interface to disabling any radio

+transmitter in the system. When a transmitter is blocked, it shall not

-Note that disabling the signal output means that the the transmitter is to be

-made to not emit any energy when "blocked". rfkill is not about blocking data

+The subsystem also provides the ability to react on button presses and

+disable all transmitters of a certain type (or all). This is intended for

+situations where transmitters need to be turned off, for example on

-The rfkill subsystem offers support for keys and switches often found on

-laptops to enable wireless devices like WiFi and Bluetooth, so that these keys

-and switches actually perform an action in all wireless devices of a given type

-The buttons to enable and disable the wireless transmitters are important in

-situations where the user is for example using his laptop on a location where

-radio-frequency transmitters _must_ be disabled (e.g. airplanes).

-Because of this requirement, userspace support for the keys should not be made

-mandatory. Because userspace might want to perform some additional smarter

-tasks when the key is pressed, rfkill provides userspace the possibility to

-===============================================================================

The rfkill subsystem is composed of various components: the rfkill class, the

rfkill-input module (an input layer handler), and some specific input layer

-The rfkill class provides kernel drivers with an interface that allows them to

-know when they should enable or disable a wireless network device transmitter.

-The rfkill class support makes sure userspace will be notified of all state

-changes on rfkill devices through uevents. It provides a notification chain

-for interested parties in the kernel to also get notified of rfkill state

-changes in other drivers. It creates several sysfs entries which can be used

-The rfkill-input module provides the kernel with the ability to implement a

-basic response when the user presses a key or button (or toggles a switch)

-related to rfkill functionality. It is an in-kernel implementation of default

-policy of reacting to rfkill-related input events and neither mandatory nor

-required for wireless drivers to operate. It is enabled by the

-rfkill-input is a rfkill-related events input layer handler. This handler will

-listen to all rfkill key events and will change the rfkill state of the

-wireless devices accordingly. With this option enabled userspace could either

-The rfkill-input module also provides EPO (emergency power-off) functionality

-for all wireless transmitters. This function cannot be overridden, and it is

-always active. rfkill EPO is related to *_RFKILL_ALL input layer events.

-In order to avoid confusion, we avoid the term "switch" in rfkill when it is

-referring to an electronic control circuit that enables or disables a

-transmitter. We reserve it for the physical device a human manipulates

- A physical device a human manipulates. Its state can be perceived by

- the kernel either directly (through a GPIO pin, ACPI GPE) or by its

- A hardware circuit that controls the state of a rfkill line, which a

- kernel driver can interact with *to modify* that state (i.e. it has

- An input channel (hardware or software) of a wireless device, which

- causes a wireless transmitter to stop emitting energy (BLOCK) when it

- is active. Point of view is extremely important here: rfkill lines are

- always seen from the PoV of a wireless device (and its driver).

- A rfkill line the wireless device driver can directly change the state

- A rfkill line that works fully in hardware or firmware, and that cannot

- be overridden by the kernel driver. The hardware device or the

- firmware just exports its status to the driver, but it is read-only.

-The enum rfkill_state describes the rfkill state of a transmitter:

-When a rfkill line or rfkill controller is in the RFKILL_STATE_UNBLOCKED state,

-the wireless transmitter (radio TX circuit for example) is *enabled*. When the

-it is in the RFKILL_STATE_SOFT_BLOCKED or RFKILL_STATE_HARD_BLOCKED, the

-RFKILL_STATE_SOFT_BLOCKED indicates that a call to toggle_radio() can change

-that state. RFKILL_STATE_HARD_BLOCKED indicates that a call to toggle_radio()

-will not be able to change the state and will return with a suitable error if

-attempts are made to set the state to RFKILL_STATE_UNBLOCKED.

-RFKILL_STATE_HARD_BLOCKED is used by drivers to signal that the device is

-locked in the BLOCKED state by a hardwire rfkill line (typically an input pin

-that, when active, forces the transmitter to be disabled) which the driver

-Full rfkill functionality requires two different subsystems to cooperate: the

-input layer and the rfkill class. The input layer issues *commands* to the

-entire system requesting that devices registered to the rfkill class change

-state. The way this interaction happens is not complex, but it is not obvious

- * Generates KEY_WWAN, KEY_WLAN, KEY_BLUETOOTH, SW_RFKILL_ALL, and

- other such events when the user presses certain keys, buttons, or

- THE INPUT LAYER IS NEVER USED TO PROPAGATE STATUS, NOTIFICATIONS OR THE

- KIND OF STUFF AN ON-SCREEN-DISPLAY APPLICATION WOULD REPORT. It is

- used to issue *commands* for the system to change behaviour, and these

- commands may or may not be carried out by some kernel driver or

- userspace application. It follows that doing user feedback based only

- on input events is broken, as there is no guarantee that an input event

- Most wireless communication device drivers implementing rfkill

- functionality MUST NOT generate these events, and have no reason to

- register themselves with the input layer. Doing otherwise is a common

- misconception. There is an API to propagate rfkill status change

- * Calls a hook in a driver to effectively change the wireless

- * Keeps track of the wireless transmitter state (with help from

- * Generates userspace notifications (uevents) and a call to a

- notification chain (kernel) when there is a wireless transmitter

- * Connects a wireless communications driver with the common rfkill

- control system, which, for example, allows actions such as

- "switch all bluetooth devices offline" to be carried out by

- THE RFKILL CLASS NEVER ISSUES INPUT EVENTS. THE RFKILL CLASS DOES

- NOT LISTEN TO INPUT EVENTS. NO DRIVER USING THE RFKILL CLASS SHALL

- EVER LISTEN TO, OR ACT ON RFKILL INPUT EVENTS. Doing otherwise is

- Most wireless data communication drivers in the kernel have just to

- implement the rfkill class API to work properly. Interfacing to the

- input layer is not often required (and is very often a *bug*) on

- Platform drivers often have to attach to the input layer to *issue*

- (but never to listen to) rfkill events for rfkill switches, and also to

- the rfkill class to export a control interface for the platform rfkill

- controllers to the rfkill subsystem. This does NOT mean the rfkill

- switch is attached to a rfkill class (doing so is almost always wrong).

- It just means the same kernel module is the driver for different

-Userspace input handlers (uevents) or kernel input handlers (rfkill-input):

- * Implements the policy of what should happen when one of the input

- * Uses the sysfs interface (userspace) or private rfkill API calls

- to tell the devices registered with the rfkill class to change

- their state (i.e. translates the input layer event into real

- * rfkill-input implements EPO by handling EV_SW SW_RFKILL_ALL 0

- (power off all transmitters) in a special way: it ignores any

- overrides and local state cache and forces all transmitters to the

- RFKILL_STATE_SOFT_BLOCKED state (including those which are already

- * rfkill EPO will remain active until rfkill-input receives an

- EV_SW SW_RFKILL_ALL 1 event. While the EPO is active, transmitters

- are locked in the blocked state (rfkill will refuse to unblock them).

- * rfkill-input implements different policies that the user can

- select for handling EV_SW SW_RFKILL_ALL 1. It will unlock rfkill,

- and either do nothing (leave transmitters blocked, but now unlocked),

- restore the transmitters to their state before the EPO, or unblock

-Userspace uevent handler or kernel platform-specific drivers hooked to the

- * Taps into the rfkill notifier chain or to KOBJ_CHANGE uevents,

- in order to know when a device that is registered with the rfkill

- * In the rare platforms where this is required, synthesizes an input

- event to command all *OTHER* rfkill devices to also change their

-===============================================================================

-Remember: point-of-view is everything for a driver that connects to the rfkill

-subsystem. All the details below must be measured/perceived from the point of

-The first thing one needs to know is whether his driver should be talking to

-the rfkill class or to the input layer. In rare cases (platform drivers), it

-could happen that you need to do both, as platform drivers often handle a

-Do not mistake input devices for rfkill controllers. The only type of "rfkill

-switch" device that is to be registered with the rfkill class are those

-directly controlling the circuits that cause a wireless transmitter to stop

-working (or the software equivalent of them), i.e. what we call a rfkill

-controller. Every other kind of "rfkill switch" is just an input device and

-A driver should register a device with the rfkill class when ALL of the

-following conditions are met (they define a rfkill controller):

-1. The device is/controls a data communications wireless transmitter;

-2. The kernel can interact with the hardware/firmware to CHANGE the wireless

-3. The transmitter can be made to not emit any energy when "blocked":

- rfkill is not about blocking data transmissions, it is about blocking

-A driver should register a device with the input subsystem to issue

-rfkill-related events (KEY_WLAN, KEY_BLUETOOTH, KEY_WWAN, KEY_WIMAX,

-SW_RFKILL_ALL, etc) when ALL of the folowing conditions are met:

-1. It is directly related to some physical device the user interacts with, to

- command the O.S./firmware/hardware to enable/disable a data communications

- Examples of the physical device are: buttons, keys and switches the user

- will press/touch/slide/switch to enable or disable the wireless

-2. It is NOT slaved to another device, i.e. there is no other device that

- issues rfkill-related input events in preference to this one.

- Please refer to the corner cases and examples section for more details.

-When in doubt, do not issue input events. For drivers that should generate

-input events in some platforms, but not in others (e.g. b43), the best solution

-is to NEVER generate input events in the first place. That work should be

-deferred to a platform-specific kernel module (which will know when to generate

-events through the rfkill notifier chain) or to userspace. This avoids the

-1. If the device is an input device that, because of hardware or firmware,

-causes wireless transmitters to be blocked regardless of the kernel's will, it

-is still just an input device, and NOT to be registered with the rfkill class.

-2. If the wireless transmitter switch control is read-only, it is an input

-device and not to be registered with the rfkill class (and maybe not to be made

-3. If there is some other device driver *closer* to the actual hardware the

-user interacted with (the button/switch/key) to issue an input event, THAT is

- [RFKILL slider switch] -- [GPIO hardware] -- [WLAN card rf-kill input]

-The user is closer to the RFKILL slide switch plaform driver, so the driver

-which must issue input events is the platform driver looking at the GPIO

-hardware, and NEVER the wireless card driver (which is just a slave). It is

-very likely that there are other leaves than just the WLAN card rf-kill input

-In this situation, the wireless card driver *could* register itself as an input

-device and issue rf-kill related input events... but in order to AVOID the need

-for DMI whitelisting, the wireless card driver does NOT do it. Userspace (HAL)

-or a platform driver (that exists only on these embedded devices) will do the

-1. NEVER confuse input device keys and buttons with input device switches.

- 1a. Switches are always set or reset. They report the current state

- 1b. Keys and buttons are either in the pressed or not-pressed state, and

- that's it. A "button" that latches down when you press it, and

- unlatches when you press it again is in fact a switch as far as input

-Add the SW_* events you need for switches, do NOT try to emulate a button using

-KEY_* events just because there is no such SW_* event yet. Do NOT try to use,

-for example, KEY_BLUETOOTH when you should be using SW_BLUETOOTH instead.

-2. Input device switches (sources of EV_SW events) DO store their current state

-(so you *must* initialize it by issuing a gratuitous input layer event on

-driver start-up and also when resuming from sleep), and that state CAN be

-queried from userspace through IOCTLs. There is no sysfs interface for this,

-but that doesn't mean you should break things trying to hook it to the rfkill

-3. Do not issue *_RFKILL_ALL events by default, unless you are sure it is the

-correct event for your switch/button. These events are emergency power-off

-events when they are trying to turn the transmitters off. An example of an

-input device which SHOULD generate *_RFKILL_ALL events is the wireless-kill

-switch in a laptop which is NOT a hotkey, but a real sliding/rocker switch.

-An example of an input device which SHOULD NOT generate *_RFKILL_ALL events by

-default, is any sort of hot key that is type-specific (e.g. the one for WLAN).

-(in this text, rfkill->foo means the foo field of struct rfkill).

-1. Each independent transmitter in a wireless device (usually there is only one

-transmitter per device) should have a SINGLE rfkill class attached to it.

-2. If the device does not have any sort of hardware assistance to allow the

-driver to rfkill the device, the driver should emulate it by taking all actions

-3. If it is impossible to silence the transmitter (i.e. it still emits energy,

-even if it is just in brief pulses, when there is no data to transmit and there

-is no hardware support to turn it off) do NOT lie to the users. Do not attach

-it to a rfkill class. The rfkill subsystem does not deal with data

-transmission, it deals with energy emission. If the transmitter is emitting

-4. It doesn't matter if the device has multiple rfkill input lines affecting

-the same transmitter, their combined state is to be exported as a single state

-This rule exists because users of the rfkill subsystem expect to get (and set,

-when possible) the overall transmitter rfkill state, not of a particular rfkill

-5. The wireless device driver MUST NOT leave the transmitter enabled during

+The rfkill class is provided for kernel drivers to register their radio

+transmitter with the kernel, provide methods for turning it on and off and,

+optionally, letting the system know about hardware-disabled states that may

+be implemented on the device. This code is enabled with the CONFIG_RFKILL

- 5.1. The transmitter has to be enabled for some sort of functionality

- like wake-on-wireless-packet or autonomous packed forwarding in a mesh

- network, and that functionality is enabled for this suspend/hibernation

+The rfkill class code also notifies userspace of state changes, this is

+achieved via uevents. It also provides some sysfs files for userspace to

+check the status of radio transmitters. See the "Userspace support" section

- 5.2. The device was not on a user-requested BLOCKED state before

- the suspend (i.e. the driver must NOT unblock a device, not even

- to support wake-on-wireless-packet or remain in the mesh).

+The rfkill-input code implements a basic response to rfkill buttons -- it

+implements turning on/off all devices of a certain class (or all).

-In other words, there is absolutely no allowed scenario where a driver can

-automatically take action to unblock a rfkill controller (obviously, this deals

-with scenarios where soft-blocking or both soft and hard blocking is happening.

-Scenarios where hardware rfkill lines are the only ones blocking the

-transmitter are outside of this rule, since the wireless device driver does not

-control its input hardware rfkill lines in the first place).

+When the device is hard-blocked (either by a call to rfkill_set_hw_state()

+or from query_hw_block) set_block() will be invoked but drivers can well

+ignore the method call since they can use the return value of the function

+rfkill_set_hw_state() to sync the software state instead of keeping track

-6. During resume, rfkill will try to restore its previous state.

-7. After a rfkill class is suspended, it will *not* call rfkill->toggle_radio

+The entire functionality is spread over more than one subsystem:

+ * The kernel input layer generates KEY_WWAN, KEY_WLAN etc. and

+ SW_RFKILL_ALL -- when the user presses a button. Drivers for radio

+ transmitters generally do not register to the input layer, unless the

+ device really provides an input device (i.e. a button that has no

-Example of a WLAN wireless driver connected to the rfkill subsystem:

---------------------------------------------------------------------

+ * The rfkill-input code hooks up to these events and switches the soft-block

+ of the various radio transmitters, depending on the button type.

-A certain WLAN card has one input pin that causes it to block the transmitter

-and makes the status of that input pin available (only for reading!) to the

-kernel driver. This is a hard rfkill input line (it cannot be overridden by

+ * The rfkill drivers turn off/on their transmitters as requested.

-The card also has one PCI register that, if manipulated by the driver, causes

-it to block the transmitter. This is a soft rfkill input line.

+ * The rfkill class will generate userspace notifications (uevents) to tell

-It has also a thermal protection circuitry that shuts down its transmitter if

-the card overheats, and makes the status of that protection available (only for

-reading!) to the kernel driver. This is also a hard rfkill input line.

-If either one of these rfkill lines are active, the transmitter is blocked by

-The driver should allocate and attach to its struct device *ONE* instance of

-It can implement the get_state() hook, and return RFKILL_STATE_HARD_BLOCKED if

-either one of its two hard rfkill input lines are active. If the two hard

-rfkill lines are inactive, it must return RFKILL_STATE_SOFT_BLOCKED if its soft

-rfkill input line is active. Only if none of the rfkill input lines are

-Since the device has a hardware rfkill line, it IS subject to state changes

-external to rfkill. Therefore, the driver must make sure that it calls

-rfkill_force_state() to keep the status always up-to-date, and it must do a

+Drivers for radio transmitters normally implement only the rfkill class.

+These drivers may not unblock the transmitter based on own decisions, they

+should act on information provided by the rfkill class only.

-Every time the driver gets a notification from the card that one of its rfkill

-lines changed state (polling might be needed on badly designed cards that don't

-generate interrupts for such events), it recomputes the rfkill state as per

+Platform drivers might implement input devices if the rfkill button is just

+that, a button. If that button influences the hardware then you need to

+implement an rfkill class instead. This also applies if the platform provides

-The driver should implement the toggle_radio() hook, that:

+During suspend/hibernation, transmitters should only be left enabled when

+wake-on wlan or similar functionality requires it and the device wasn't

+blocked before suspend/hibernate. Note that it may be necessary to update

+the rfkill subsystem's idea of what the current state is at resume time if

-1. Returns an error if one of the hardware rfkill lines are active, and the

-2. Activates the soft rfkill line if the caller asked for state

-RFKILL_STATE_SOFT_BLOCKED. It should do this even if one of the hard rfkill

-lines are active, effectively double-blocking the transmitter.

-3. Deactivates the soft rfkill line if none of the hardware rfkill lines are

-===============================================================================

To build a driver with rfkill subsystem support, the driver should depend on

-(or select) the Kconfig symbol RFKILL; it should _not_ depend on RKFILL_INPUT.

The hardware the driver talks to may be write-only (where the current state

of the hardware is unknown), or read-write (where the hardware can be queried

-The rfkill class will call the get_state hook of a device every time it needs

-to know the *real* current state of the hardware. This can happen often, but

-it does not do any polling, so it is not enough on hardware that is subject

-Therefore, calling rfkill_force_state() when a state change happens is

-mandatory when the device has a hardware rfkill line, or when something else

-like the firmware could cause its state to be changed without going through the

-Some hardware provides events when its status changes. In these cases, it is

-best for the driver to not provide a get_state hook, and instead register the

-rfkill class *already* with the correct status, and keep it updated using

-rfkill_force_state() when it gets an event from the hardware.

-rfkill_force_state() must be used on the device resume handlers to update the

-rfkill status, should there be any chance of the device status changing during

-There is no provision for a statically-allocated rfkill struct. You must

- - modify state to the current hardware state (THIS IS THE ONLY TIME

-The only way to set a device to the RFKILL_STATE_HARD_BLOCKED state is through

-a suitable return of get_state() or through rfkill_force_state().

+Calling rfkill_set_hw_state() when a state change happens is required from

+rfkill drivers that control devices that can be hard-blocked unless they also

+assign the poll_hw_block() callback (then the rfkill core will poll the

+device). Don't do this unless you cannot get the event in any other way.

-When a device is in the RFKILL_STATE_HARD_BLOCKED state, the only way to switch

-it to a different state is through a suitable return of get_state() or through

-If toggle_radio() is called to set a device to state RFKILL_STATE_SOFT_BLOCKED

-when that device is already at the RFKILL_STATE_HARD_BLOCKED state, it should

-not return an error. Instead, it should try to double-block the transmitter,

-so that its state will change from RFKILL_STATE_HARD_BLOCKED to

-RFKILL_STATE_SOFT_BLOCKED should the hardware blocking cease.

-===============================================================================

-rfkill devices issue uevents (with an action of "change"), with the following

-The ABI for these variables is defined by the sysfs attributes. It is best

-to take a quick look at the source to make sure of the possible values.

-It is expected that HAL will trap those, and bridge them to DBUS, etc. These

-events CAN and SHOULD be used to give feedback to the user about the rfkill

-Input devices may issue events that are related to rfkill. These are the

-various KEY_* events and SW_* events supported by rfkill-input.c.

-When rfkill-input is ACTIVE, userspace is NOT TO CHANGE THE STATE OF AN RFKILL

-SWITCH IN RESPONSE TO AN INPUT EVENT also handled by rfkill-input, unless it

-has set to true the user_claim attribute for that particular switch. This rule

-Userspace must not assume it is the only source of control for rfkill switches.

-Their state CAN and WILL change due to firmware actions, direct user actions,

-When rfkill-input is not active, userspace must initiate a rfkill status

-change by writing to the "state" attribute in order for anything to happen.

-Take particular care to implement EV_SW SW_RFKILL_ALL properly. When that

-switch is set to OFF, *every* rfkill device *MUST* be immediately put into the

+The following sysfs entries exist for every rfkill device:

name: Name assigned by driver to this key (interface or driver name).

- claim: 1: Userspace handles events, 0: Kernel handles events

-Both the "state" and "claim" entries are also writable. For the "state" entry

-this means that when 1 or 0 is written, the device rfkill state (if not yet in

-the requested state), will be will be toggled accordingly.

-For the "claim" entry writing 1 to it means that the kernel no longer handles

-key events even though RFKILL_INPUT input was enabled. When "claim" has been

-set to 0, userspace should make sure that it listens for the input events or

-check the sysfs "state" entry regularly to correctly perform the required tasks

-In order to know the current state of an input device switch (like

-SW_RFKILL_ALL), you will need to use an IOCTL. That information is not

-available through sysfs in a generic way at this time, and it is not available

+ claim: 0: Kernel handles events (currently always reads that value)

+rfkill devices also issue uevents (with an action of "change"), with the

+The contents of these variables corresponds to the "name", "state" and

+An alternative userspace interface exists as a misc device /dev/rfkill,

+which allows userspace to obtain and set the state of rfkill devices and

+sets of devices. It also notifies userspace about device addition and

+removal. The API is a simple read/write API that is defined in

diff --git a/Documentation/s390/Debugging390.txt b/Documentation/s390/Debugging390.txt
index 10711d9f0788..1eb576a023bd 100644
--- a/Documentation/s390/Debugging390.txt
+++ b/Documentation/s390/Debugging390.txt

@@ -2211,7 +2211,7 @@ Breakpoint 2 at 0x4d87a4: file top.c, line 2609.

#6 0x5164fe in readline (prompt=0x7ffff810 "\177ÿøx\177ÿ÷Ø\177ÿøxÀ")

-#7 0x4d7a8a in command_line_input (prrompt=0x564420 "(gdb) ", repeat=1,

+#7 0x4d7a8a in command_line_input (prompt=0x564420 "(gdb) ", repeat=1,

#9 0x4e25bc in main (argc=1, argv=0x7ffffdf4) at main.c:635

diff --git a/Documentation/scheduler/sched-nice-design.txt b/Documentation/scheduler/sched-nice-design.txt
index e2bae5a577e3..3ac1e46d5365 100644
--- a/Documentation/scheduler/sched-nice-design.txt
+++ b/Documentation/scheduler/sched-nice-design.txt

@@ -55,7 +55,7 @@ To sum it up: we always wanted to make nice levels more consistent, but

within the constraints of HZ and jiffies and their nasty design level

coupling to timeslices and granularity it was not really viable.

-The second (less frequent but still periodically occuring) complaint

+The second (less frequent but still periodically occurring) complaint

about Linux's nice level support was its assymetry around the origo

(which you can see demonstrated in the picture above), or more

accurately: the fact that nice level behavior depended on the _absolute_

diff --git a/Documentation/scheduler/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt
index 5ba4d3fc625a..1df7f9cdab05 100644
--- a/Documentation/scheduler/sched-rt-group.txt
+++ b/Documentation/scheduler/sched-rt-group.txt

+ Fiddling with these settings can result in an unstable system, the knobs are

+ * very small values in sched_rt_period_us can result in an unstable

+ system when the period is smaller than either the available hrtimer

+ resolution, or the time it takes to handle the budget refresh itself.

+ * very small values in sched_rt_runtime_us can result in an unstable

+ system when the runtime is so small the system has difficulty making

+ forward progress (NOTE: the migration thread and kstopmachine both

Implementing SCHED_EDF might take a while to complete. Priority Inheritance is

the biggest challenge as the current linux PI infrastructure is geared towards

-the limited static priority levels 0-139. With deadline scheduling you need to

+the limited static priority levels 0-99. With deadline scheduling you need to

do deadline inheritance (since priority is inversely proportional to the

diff --git a/Documentation/scsi/aic79xx.txt b/Documentation/scsi/aic79xx.txt
index 683ccae00ad4..c014eccaf19f 100644
--- a/Documentation/scsi/aic79xx.txt
+++ b/Documentation/scsi/aic79xx.txt

@@ -194,7 +194,7 @@ The following information is available in this file:

diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt
index 230e30846ef2..08e2b4d04aab 100644
--- a/Documentation/scsi/ncr53c8xx.txt
+++ b/Documentation/scsi/ncr53c8xx.txt

The 896 and the 895A allows handling of the phase mismatch context from

SCRIPTS (avoids the phase mismatch interrupt that stops the SCSI processor

-Implementing this without using LOAD/STORE instructions would be painfull

+Implementing this without using LOAD/STORE instructions would be painful

The 896 chip supports 64 bit PCI transactions and addressing, while the

@@ -240,7 +240,7 @@ characteristics. This feature may also reduce average command latency.

In order to really gain advantage of this feature, devices must have

a reasonable cache size (No miracle is to be expected for a low-end

-Some kown SCSI devices do not properly support tagged command queuing.

+Some known SCSI devices do not properly support tagged command queuing.

Generally, firmware revisions that fix this kind of problems are available

All I can say is that the hard disks I use on my machines behave well with

diff --git a/Documentation/scsi/sym53c8xx_2.txt b/Documentation/scsi/sym53c8xx_2.txt
index 49ea5c58c6bc..eb9a7b905b64 100644
--- a/Documentation/scsi/sym53c8xx_2.txt
+++ b/Documentation/scsi/sym53c8xx_2.txt

@@ -206,7 +206,7 @@ characteristics. This feature may also reduce average command latency.

In order to really gain advantage of this feature, devices must have

a reasonable cache size (No miracle is to be expected for a low-end

-Some kown old SCSI devices do not properly support tagged command queuing.

+Some known old SCSI devices do not properly support tagged command queuing.

Generally, firmware revisions that fix this kind of problems are available

All I can say is that I never have had problem with tagged queuing using

diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index 012858d2b119..4252697a95d6 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt

@@ -460,6 +460,25 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.

+ Module for Creative Sound Blaster X-Fi boards (20k1 / 20k2 chips)

+ * Creative Sound Blaster X-Fi Titanium Fatal1ty Champion Series

+ * Creative Sound Blaster X-Fi Titanium Fatal1ty Professional Series

+ * Creative Sound Blaster X-Fi Titanium Professional Audio

+ reference_rate - reference sample rate, 44100 or 48000 (default)

+ multiple - multiple to ref. sample rate, 1 or 2 (default)

@@ -754,7 +773,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.

single_cmd - Use single immediate commands to communicate with

enable_msi - Enable Message Signaled Interrupt (MSI) (default = off)

- power_save - Automatic power-saving timtout (in second, 0 =

+ power_save - Automatic power-saving timeout (in second, 0 =

power_save_controller - Reset HD-audio controller in power-saving mode

@@ -925,6 +944,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.

@@ -933,7 +953,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.

@@ -1093,6 +1113,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.

The driver requires the firmware loader support on kernel.

@@ -1543,13 +1570,15 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.

+ Module for Gallant SC-6000 soundcard and later models: SC-6600

+ joystick - Enable gameport - 0 = disable (default), 1 = enable

@@ -1859,7 +1888,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.

Module for sound cards based on the Asus AV100/AV200 chips,

- i.e., Xonar D1, DX, D2, D2X, HDAV1.3 (Deluxe), and Essence STX.

+ i.e., Xonar D1, DX, D2, D2X, HDAV1.3 (Deluxe), Essence ST

diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt
index 8eec05bc079e..de8e10a94103 100644
--- a/Documentation/sound/alsa/HD-Audio-Models.txt
+++ b/Documentation/sound/alsa/HD-Audio-Models.txt

test for testing/debugging purpose, almost all controls can

acer Acer laptops (Travelmate 3012WTMi, Aspire 5600, etc)

laptop-eapd 3-jack with SPDIF I/O and EAPD (Clevo M540JE, M550JE)

diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt
index 88b7433d2f11..71ac995b1915 100644
--- a/Documentation/sound/alsa/HD-Audio.txt
+++ b/Documentation/sound/alsa/HD-Audio.txt

The HD-audio component consists of two parts: the controller chip and

the codec chips on the HD-audio bus. Linux provides a single driver

for all controllers, snd-hda-intel. Although the driver name contains

-a word of a well-known harware vendor, it's not specific to it but for

+a word of a well-known hardware vendor, it's not specific to it but for

all controller chips by other companies. Since the HD-audio

controllers are supposed to be compatible, the single snd-hda-driver

should work in most cases. But, not surprisingly, there are known

diff --git a/Documentation/sound/alsa/Procfile.txt b/Documentation/sound/alsa/Procfile.txt
index bba2dbb79d81..381908d8ca42 100644
--- a/Documentation/sound/alsa/Procfile.txt
+++ b/Documentation/sound/alsa/Procfile.txt

- This shows the status of xrun (= buffer overrun/xrun) debug of

- ALSA PCM middle layer, as an integer from 0 to 2. The value

- When this value is greater than 0, the driver will show the

- messages to kernel log when an xrun is detected. The debug

- message is shown also when the invalid H/W pointer is detected

- at the update of periods (usually called from the interrupt

+ This shows the status of xrun (= buffer overrun/xrun) and

+ invalid PCM position debug/check of ALSA PCM middle layer.

+ It takes an integer value, can be changed by writing to this

+ When the bit 0 is set, the driver will show the messages to

+ kernel log when an xrun is detected. The debug message is

+ shown also when the invalid H/W pointer is detected at the

- When this value is greater than 1, the driver will show the

+ When the bit 1 is set, the driver will show the stack trace

+ Since 2.6.30, this option can enable the hwptr check using

+ jiffies. This detects spontaneous invalid pointer callback

+ values, but can be lead to too much corrections for a (mostly

+ buggy) hardware that doesn't give smooth pointer updates.

diff --git a/Documentation/sound/alsa/README.maya44 b/Documentation/sound/alsa/README.maya44
new file mode 100644
index 000000000000..0e41576fa13e
--- /dev/null
+++ b/Documentation/sound/alsa/README.maya44

+NOTE: The following is the original document of Rainer's patch that the

+current maya44 code based on. Some contents might be obsoleted, but I

+----------------------------------------------------------------

+This driver is being developed on the initiative of Piotr Makowski (oponek@gmail.com) and financed by Lars Bergmann.

+Development is carried out by Rainer Zimmermann (mail@lightshed.de).

+ESI provided a sample Maya44 card for the development work.

+However, unfortunately it has turned out difficult to get detailed programming information, so I (Rainer Zimmermann) had to find out some card-specific information by experiment and conjecture. Some information (in particular, several GPIO bits) is still missing.

+This is the first testing version of the Maya44 driver released to the alsa-devel mailing list (Feb 5, 2008).

+The following functions work, as tested by Rainer Zimmermann and Piotr Makowski:

+The following functions *should* work, but are not fully tested:

+*In particular, we would appreciate testing of these functions by anyone who has access to an M/IO/DIO extension card.*

+- The level meters ("multi track") in 'alsamixer' do not seem to react to signals in (if this is a bug, it would probably be in the existing ICE1724 code).

+- Ardour 2.1 seems to work only via JACK, not using ALSA directly or via OSS. This still needs to be tracked down.

+pci/ice1724/ice1724.h.patch - PROPOSED patch to ice1724.h (see SAMPLING RATES)

+i2c/other/wm8776.c - low-level access routines for Wolfson WM8776 codecs

+Note that the wm8776.c code is meant to be card-independent and does not actually register the codec with the ALSA infrastructure.

+This is done in maya44.c, mainly because some of the WM8776 controls are used in Maya44-specific ways, and should be named appropriately.

+the following files were created in pci/ice1724, simply #including the corresponding file from the alsa-kernel tree:

+The Maya44 card (or more exactly, the Wolfson WM8776 codecs) allow a maximum sampling rate of 192 kHz for playback and 92 kHz for capture.

+As the ICE1724 chip only allows one global sampling rate, this is handled as follows:

+* setting the sampling rate on any open PCM device on the maya44 card will always set the *global* sampling rate for all playback and capture channels.

+* In the current state of the driver, setting rates of up to 192 kHz is permitted even for capture devices.

+*AVOID CAPTURING AT RATES ABOVE 96kHz*, even though it may appear to work. The codec cannot actually capture at such rates, meaning poor quality.

+I propose some additional code for limiting the sampling rate when setting on a capture pcm device. However because of the global sampling rate, this logic would be somewhat problematic.

+The proposed code (currently deactivated) is in ice1712.h.patch, ice1724.c and maya44.c (in pci/ice1712).

+PCM devices correspond to inputs/outputs as follows (assuming Maya44 is card #0):

+hw:0,1 output - stereo, analog output 3+4 (and SPDIF out)

+(for more information about the signal flow, please refer to the block diagram on p.24 of the ESI Maya44 manual, or in the ESI windows software).

+Mic Phantom+48V: switch for +48V phantom power for electrostatic microphones on input 1/2.

+ Make sure this is not turned on while any other source is connected to input 1/2.

+Mic/Line input: if switch is is on, input jack 1/2 is microphone input (mono), otherwise line input (stereo).

+Bypass: analogue bypass from ADC input to output for channel 1+2. Same as "Monitor" in the windows driver.

+Crossmix 1: cross-mixer from channels 3+4 to channels 1+2

+ S/PDIF should output the same signal as channel 3+4. [untested!]

+ These switches allow a direct digital routing from the ADCs to the DACs.

+ Each switch determines where the digital input data to one of the DACs comes from.

+ For normal operation, they should all be set to "PCM out".

+H/W 4 ... H/W 9: unknown function, left in to enable testing.

+ If these turn out to be unused, they will go away in later driver versions.

+Selectable values for each of the digital output selectors are:

+ "PCM out" -> DAC output of the corresponding channel (default setting)

+ "Input 4" -> direct routing from ADC output of the selected input channel

diff --git a/Documentation/sound/alsa/hda_codec.txt b/Documentation/sound/alsa/hda_codec.txt
index 34e87ec1379c..de8efbc7e4bd 100644
--- a/Documentation/sound/alsa/hda_codec.txt
+++ b/Documentation/sound/alsa/hda_codec.txt

@@ -114,7 +114,7 @@ For writing a sequence of verbs, use snd_hda_sequence_write().

There are variants of cached read/write, snd_hda_codec_write_cache(),

snd_hda_sequence_write_cache(). These are used for recording the

-register states for the power-mangement resume. When no PM is needed,

+register states for the power-management resume. When no PM is needed,

To retrieve the number of sub nodes connected to the given node, use

diff --git a/Documentation/sound/alsa/soc/dapm.txt b/Documentation/sound/alsa/soc/dapm.txt
index 9e6763264a2e..9ac842be9b4f 100644
--- a/Documentation/sound/alsa/soc/dapm.txt
+++ b/Documentation/sound/alsa/soc/dapm.txt

@@ -62,6 +62,7 @@ Audio DAPM widgets fall into a number of types:-

+ o Supply - Power or clock supply widget used by other widgets.

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index f11ca7979fa6..322a00bb99d9 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt

==============================================================

+A toggle value indicating if modules are allowed to be loaded

+in an otherwise modular kernel. This toggle defaults to off

+neither loaded nor unloaded, and the toggle cannot be set back

+==============================================================

diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index c302ddf629a0..c4de6359d440 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt

@@ -233,8 +233,8 @@ These protections are added to score to judge whether this zone should be used

In this example, if normal pages (index=2) are required to this DMA zone and

-pages_high is used for watermark, the kernel judges this zone should not be

-used because pages_free(1355) is smaller than watermark + protection[2]

+watermark[WMARK_HIGH] is used for watermark, the kernel judges this zone should

+not be used because pages_free(1355) is smaller than watermark + protection[2]

(4 + 2004 = 2008). If this protection value is 0, this zone would be used for

normal page requirement. If requirement is DMA zone(index=0), protection[0]

This is used to force the Linux VM to keep a minimum number

-of kilobytes free. The VM uses this number to compute a pages_min

-value for each lowmem zone in the system. Each lowmem zone gets

-a number of reserved free pages based proportionally on its size.

+watermark[WMARK_MIN] value for each lowmem zone in the system.

+Each lowmem zone gets a number of reserved free pages based

Some minimal amount of memory is needed to satisfy PF_MEMALLOC

allocations; if you set this to lower than 1024KB, your system will

-A percentage of the total pages in each zone. Zone reclaim will only

-occur if more than this percentage of pages are file backed and unmapped.

-This is to insure that a minimal amount of local pages is still available for

+This is a percentage of the total pages in each zone. Zone reclaim will

+only occur if more than this percentage of pages are in a state that

+If zone_reclaim_mode has the value 4 OR'd, then the percentage is compared

+against all file-backed unmapped pages including swapcache pages and tmpfs

+files. Otherwise, only unmapped pages backed by normal files but not tmpfs

The current number of pdflush threads. This value is read-only.

The value changes according to the number of dirty pages in the system.

-When neccessary, additional pdflush threads are created, one per second, up to

+When necessary, additional pdflush threads are created, one per second, up to

==============================================================

This control is used to define how aggressive the kernel will swap

memory pages. Higher values will increase agressiveness, lower values

diff --git a/Documentation/timers/hpet.txt b/Documentation/timers/hpet.txt
index e7c09abcfab4..04763a325520 100644
--- a/Documentation/timers/hpet.txt
+++ b/Documentation/timers/hpet.txt

@@ -7,7 +7,7 @@ by Intel and Microsoft which can be found at

Each HPET has one fixed-rate counter (at 10+ MHz, hence "High Precision")

and up to 32 comparators. Normally three or more comparators are provided,

-each of which can generate oneshot interupts and at least one of which has

+each of which can generate oneshot interrupts and at least one of which has

additional hardware to support periodic interrupts. The comparators are

also called "timers", which can be misleading since usually timers are

independent of each other ... these share a counter, complicating resets.

diff --git a/Documentation/timers/timer_stats.txt b/Documentation/timers/timer_stats.txt
index 20d368c59814..9bd00fc2e823 100644
--- a/Documentation/timers/timer_stats.txt
+++ b/Documentation/timers/timer_stats.txt

The first column is the number of events, the second column the pid, the third

column is the name of the process. The forth column shows the function which

-initialized the timer and in parantheses the callback function which was

+initialized the timer and in parenthesis the callback function which was

diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index fd9a3e693813..a39b3c749de5 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt

Ftrace uses the debugfs file system to hold the control files as

+When debugfs is configured into the kernel (which selecting any ftrace

+option will do) the directory /sys/kernel/debug will be created. To mount

+For quicker access to that directory you may want to make a soft link to

-( Note: it is more common to mount at /sys/kernel/debug, but for

+Any selected ftrace option will also create a directory called tracing

+within the debugfs. The rest of the document will assume that you are in

+the ftrace directory (cd /sys/kernel/debug/tracing) and will only concentrate

+on the files within that directory and not distract from the content with

That's it! (assuming that you have ftrace configured into your kernel)

@@ -179,7 +191,7 @@ Here is the list of current tracers that may be configured.

The trace_options file is used to control what gets printed in

the trace output. To see what is available, simply cat the file:

print-parent nosym-offset nosym-addr noverbose noraw nohex nobin \

noblock nostacktrace nosched-tree nouserstacktrace nosym-userobj

To disable one of the options, echo in the option prepended with

This tracer simply records schedule switches. Here is an example

@@ -518,9 +530,18 @@ priority with zero (0) being the highest priority and the nice

values starting at 100 (nice -20). Below is a quick chart to map

+ ===============================================================

+ ---------------------------------------------------------------

To reset the maximum, echo 0 into tracing_max_latency. Here is

@@ -681,13 +702,13 @@ Like the irqsoff tracer, it records the maximum latency for

which preemption was disabled. The control of preemptoff tracer

Again, using this trace is much like the irqsoff and preemptoff

@@ -990,12 +1011,12 @@ slightly differently than we did with the previous tracers.

Instead of performing an 'ls', we will run 'sleep 1' under

@@ -1105,11 +1126,11 @@ can be done from the debug file system. Make sure the

- trace_fd = open("/debug/tracing/tracing_enabled", O_WRONLY);

+ trace_fd = open(tracing_file("tracing_enabled"), O_WRONLY);

@@ -1154,26 +1175,20 @@ int main(int argc, char *argv[]) {

-Note: Here we hard coded the path name. The debugfs mount is not

-/sys/kernel/debug). For simple one time traces, the above is

-sufficent. For anything else, a search through /proc/mounts may

-be needed to find where the debugfs file-system is mounted.

-By writing into /debug/tracing/set_ftrace_pid you can trace a

yum-updatesd-3111 [003] 1637.254683: lock_hrtimer_base <-hrtimer_try_to_cancel

yum-updatesd-3111 [003] 1637.254685: fget_light <-do_sys_poll

yum-updatesd-3111 [003] 1637.254686: pipe_poll <-do_sys_poll

@@ -1207,6 +1222,51 @@ something like this simple program:

+ snprintf(trace_file, MAX_PATH, "%s/%s", find_debugfs(), file_name);

tracing_cpu_mask file) or you might sometimes see unordered

- hide: echo nofuncgraph-cpu > /debug/tracing/trace_options

- show: echo funcgraph-cpu > /debug/tracing/trace_options

- The duration (function's time of execution) is displayed on

the closing bracket line of a function or on the same line

than the current function in case of a leaf one. It is default

- hide: echo nofuncgraph-duration > /debug/tracing/trace_options

- show: echo funcgraph-duration > /debug/tracing/trace_options

- The overhead field precedes the duration field in case of

- hide: echo nofuncgraph-overhead > /debug/tracing/trace_options

- show: echo funcgraph-overhead > /debug/tracing/trace_options

- The task/pid field displays the thread cmdline and pid which

- hide: echo nofuncgraph-proc > /debug/tracing/trace_options

- show: echo funcgraph-proc > /debug/tracing/trace_options

system clock since it started. A snapshot of this time is

- hide: echo nofuncgraph-abstime > /debug/tracing/trace_options

- show: echo funcgraph-abstime > /debug/tracing/trace_options

If I am only interested in sys_nanosleep and hrtimer_interrupt:

@@ -1568,7 +1628,7 @@ If I am only interested in sys_nanosleep and hrtimer_interrupt:

To see which functions are being traced, you can cat the file:

@@ -1588,7 +1648,7 @@ Note: It is better to use quotes to enclose the wild cards,

@@ -1635,17 +1695,17 @@ To append to the filters, use '>>'

To clear out a filter so that all functions will be recorded

- # echo sys_nanosleep > /debug/tracing/set_ftrace_filter

The set_ftrace_notrace prevents those functions from being

- # echo '*preempt*' '*lock*' > /debug/tracing/set_ftrace_notrace

@@ -1758,13 +1818,13 @@ the effect on the tracing is different. Every read from

trace_pipe is consumed. This means that subsequent reads will be

@@ -1800,7 +1860,7 @@ number listed is the number of entries that can be recorded per

CPU. To know the full size, multiply the number of possible CPUS

Note, to modify this, you must have tracing completely disabled.

@@ -1808,21 +1868,21 @@ To do that, echo "nop" into the current_tracer. If the

current_tracer is not set to "nop", an EINVAL error will be

The number of pages which will be allocated is limited to a

percentage of available memory. Allocating too much will produce

diff --git a/Documentation/trace/kmemtrace.txt b/Documentation/trace/kmemtrace.txt
index a956d9b7f943..6308735e58ca 100644
--- a/Documentation/trace/kmemtrace.txt
+++ b/Documentation/trace/kmemtrace.txt

-$ git-clone git://repo.or.cz/kmemtrace-user.git # current repository

+$ git clone git://repo.or.cz/kmemtrace-user.git # current repository

diff --git a/Documentation/trace/mmiotrace.txt b/Documentation/trace/mmiotrace.txt
index 5731c67abc55..162effbfbdec 100644
--- a/Documentation/trace/mmiotrace.txt
+++ b/Documentation/trace/mmiotrace.txt

@@ -32,41 +32,41 @@ is no way to automatically detect if you are losing events due to CPUs racing.

+$ echo mmiotrace > /sys/kernel/debug/tracing/current_tracer

+$ cat /sys/kernel/debug/tracing/trace_pipe > mydump.txt &

+$ echo "X is up" > /sys/kernel/debug/tracing/trace_marker

-Make sure debugfs is mounted to /debug. If not, (requires root privileges)

+Make sure debugfs is mounted to /sys/kernel/debug. If not, (requires root privileges)

Check that the driver you are about to trace is not loaded.

+$ echo mmiotrace > /sys/kernel/debug/tracing/current_tracer

+$ cat /sys/kernel/debug/tracing/trace_pipe > mydump.txt &

The 'cat' process should stay running (sleeping) in the background.

Load the driver you want to trace and use it. Mmiotrace will only catch MMIO

accesses to areas that are ioremapped while mmiotrace is active.

During tracing you can place comments (markers) into the trace by

+$ echo "X is up" > /sys/kernel/debug/tracing/trace_marker

This makes it easier to see which part of the (huge) trace corresponds to

which action. It is recommended to place descriptive markers about what you

The 'cat' process exits. If it does not, kill it by issuing 'fg' command and

@@ -78,10 +78,10 @@ to view your kernel log and look for "mmiotrace has lost events" warning. If

events were lost, the trace is incomplete. You should enlarge the buffers and

try again. Buffers are enlarged by first seeing how large the current buffers

gives you a number. Approximately double this number and write it back, for

+$ echo 128000 > /sys/kernel/debug/tracing/buffer_size_kb

If you are doing a trace for a driver project, e.g. Nouveau, you should also

diff --git a/Documentation/usb/WUSB-Design-overview.txt b/Documentation/usb/WUSB-Design-overview.txt
index 4c3d62c7843a..c480e9c32dbd 100644
--- a/Documentation/usb/WUSB-Design-overview.txt
+++ b/Documentation/usb/WUSB-Design-overview.txt

@@ -84,7 +84,7 @@ The different logical parts of this driver are:

*UWB*: the Ultra-Wide-Band stack -- manages the radio and

associated spectrum to allow for devices sharing it. Allows to

@@ -184,7 +184,7 @@ and sends the replies and notifications back to the API

[/uwb_rc_neh_grok()/]. Notifications are handled to the UWB daemon, that

is chartered, among other things, to keep the tab of how the UWB radio

neighborhood looks, creating and destroying devices as they show up or

Command execution is very simple: a command block is sent and a event

block or reply is expected back. For sending/receiving command/events, a

-Everytime there is a succesful transfer to/from a device, we update a

+Every time there is a successful transfer to/from a device, we update a

per-device activity timestamp. If not, every now and then we check and

if the activity timestamp gets old, we ping the device by sending it a

Keep Alive IE; it responds with a /DN_Alive/ pong during the DNTS (this

@@ -411,7 +411,7 @@ context (wa_xfer) and submit it. When the xfer is done, our callback is

called and we assign the status bits and release the xfer resources.

In dequeue() we are basically cancelling/aborting the transfer. We issue

-a xfer abort request to the HC, cancell all the URBs we had submitted

+a xfer abort request to the HC, cancel all the URBs we had submitted

and not yet done and when all that is done, the xfer callback will be

diff --git a/Documentation/usb/anchors.txt b/Documentation/usb/anchors.txt
index 6f24f566955a..fe6a99a32bbd 100644
--- a/Documentation/usb/anchors.txt
+++ b/Documentation/usb/anchors.txt

@@ -27,7 +27,7 @@ Association and disassociation of URBs with anchors

An association of URBs to an anchor is made by an explicit

call to usb_anchor_urb(). The association is maintained until

-an URB is finished by (successfull) completion. Thus disassociation

+an URB is finished by (successful) completion. Thus disassociation

is automatic. A function is provided to forcibly finish (kill)

Furthermore, disassociation can be made with usb_unanchor_urb()

Returns the oldest anchored URB of an anchor. The URB is unanchored

and returned with a reference. As you may mix URBs to several

destinations in one anchor you have no guarantee the chronologically

-first submitted URB is returned. \ No newline at end of file

diff --git a/Documentation/usb/callbacks.txt b/Documentation/usb/callbacks.txt
index 7c812411945b..bfb36b34b79e 100644
--- a/Documentation/usb/callbacks.txt
+++ b/Documentation/usb/callbacks.txt

@@ -65,7 +65,7 @@ Accept or decline an interface. If you accept the device return 0,

otherwise -ENODEV or -ENXIO. Other error codes should be used only if a

genuine error occurred during initialisation which prevented a driver

from accepting a device that would else have been accepted.

usb_set_intfdata(), to associate a data structure with an interface, so

that you know which internal state and identity you associate with a

particular interface. The device will not be suspended and you may do IO

diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885
index 91aa3c0f0dd2..450b8f8c389b 100644
--- a/Documentation/video4linux/CARDLIST.cx23885
+++ b/Documentation/video4linux/CARDLIST.cx23885

diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88
index 71e9db0b26f7..89093f531727 100644
--- a/Documentation/video4linux/CARDLIST.cx88
+++ b/Documentation/video4linux/CARDLIST.cx88

diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index 78d0a6eed571..a98a688c11b8 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx

16 -> Hauppauge WinTV HVR 950 (em2883) [2040:6513,2040:6517,2040:651b]

21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder (em2800) [eb1a:2801]

22 -> Unknown EM2750/EM2751 webcam grabber (em2750) [eb1a:2750,eb1a:2751]

+ 69 -> KWorld ATSC 315U HDTV TV Box (em2882) [eb1a:a313]

diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 6dacf2825259..15562427e8a9 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134

-126 -> Beholder BeholdTV 505 FM/RDS [0000:5051,0000:505B,5ace:5050]

-127 -> Beholder BeholdTV 507 FM/RDS / BeholdTV 509 FM [0000:5071,0000:507B,5ace:5070,5ace:5090]

+127 -> Beholder BeholdTV 507 FM / BeholdTV 509 FM [5ace:5070,5ace:5090]

-129 -> Beholder BeholdTV 607 / BeholdTV 609 [5ace:6070,5ace:6071,5ace:6072,5ace:6073,5ace:6090,5ace:6091,5ace:6092,5ace:6093]

+145 -> AVerMedia MiniPCI DVB-T Hybrid M103 [1461:f636,1461:f736]

155 -> Hauppauge WinTV-HVR1120 ATSC/QAM-Hybrid [0070:6706,0070:6708]

-156 -> Hauppauge WinTV-HVR1110r3 [0070:6707,0070:6709,0070:670a]

+156 -> Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid [0070:6707,0070:6709,0070:670a]

diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner
index 691d2f37dc57..be67844074dd 100644
--- a/Documentation/video4linux/CARDLIST.tuner
+++ b/Documentation/video4linux/CARDLIST.tuner

+tuner=80 - Philips FQ1216LME MK3 PAL/SECAM w/active loopthrough

diff --git a/Documentation/video4linux/cx18.txt b/Documentation/video4linux/cx18.txt
index 914cb7e734a2..4652c0f5da32 100644
--- a/Documentation/video4linux/cx18.txt
+++ b/Documentation/video4linux/cx18.txt

2) Some people have problems getting the i2c bus to work.

The symptom is that the eeprom cannot be read and the card is

unusable. This is probably fixed, but if you have problems

- then post to the video4linux or ivtv-users mailinglist.

+ then post to the video4linux or ivtv-users mailing list.

diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt
index 98529e03a46e..2bcf78896e22 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt

diff --git a/Documentation/video4linux/pxa_camera.txt b/Documentation/video4linux/pxa_camera.txt
index b1137f9a53eb..4f6d0ca01956 100644
--- a/Documentation/video4linux/pxa_camera.txt
+++ b/Documentation/video4linux/pxa_camera.txt

Once the last buffer is filled in, the QCI interface stops.

++-> | QCI: stop | ------------------> | QCI: run | <------------+

+| +--------------------+ / +----------------------+ | Other |

+ +--------------------+ <-----+ +----------------------+ restart frame |

+ - each arrow is the condition to transition to another state

+ - an arrow with a comment is a mandatory transition (no condition)

+ - "DMA: run" means at least 1 DMA channel is still running

diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index 854808b67fae..d54c1e4c6a9c 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt

@@ -89,6 +89,11 @@ from dev (driver name followed by the bus_id, to be precise). If you set it

up before calling v4l2_device_register then it will be untouched. If dev is

NULL, then you *must* setup v4l2_dev->name before calling v4l2_device_register.

+You can use v4l2_device_set_name() to set the name based on a driver name and

+a driver-global atomic_t instance. This will generate names like ivtv0, ivtv1,

+etc. If the name ends with a digit, then it will insert a dash: cx18-0,

The first 'dev' argument is normally the struct device pointer of a pci_dev,

usb_interface or platform_device. It is rare for dev to be NULL, but it happens

with ISA devices or when one device creates multiple PCI devices, thus making

diff --git a/Documentation/vm/Makefile b/Documentation/vm/Makefile
index 6f562f778b28..27479d43a9b0 100644
--- a/Documentation/vm/Makefile
+++ b/Documentation/vm/Makefile

diff --git a/Documentation/vm/balance b/Documentation/vm/balance
index bd3d31bc4915..c46e68cf9344 100644
--- a/Documentation/vm/balance
+++ b/Documentation/vm/balance

@@ -75,15 +75,15 @@ Page stealing from process memory and shm is done if stealing the page would

alleviate memory pressure on any zone in the page's node that has fallen below

-pages_min/pages_low/pages_high/low_on_memory/zone_wake_kswapd: These are

-per-zone fields, used to determine when a zone needs to be balanced. When

-the number of pages falls below pages_min, the hysteric field low_on_memory

-gets set. This stays set till the number of free pages becomes pages_high.

-When low_on_memory is set, page allocation requests will try to free some

-pages in the zone (providing GFP_WAIT is set in the request). Orthogonal

-to this, is the decision to poke kswapd to free some zone pages. That

-decision is not hysteresis based, and is done when the number of free

-pages is below pages_low; in which case zone_wake_kswapd is also set.

+watemark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd: These

+are per-zone fields, used to determine when a zone needs to be balanced. When

+the number of pages falls below watermark[WMARK_MIN], the hysteric field

+low_on_memory gets set. This stays set till the number of free pages becomes

+watermark[WMARK_HIGH]. When low_on_memory is set, page allocation requests will

+try to free some pages in the zone (providing GFP_WAIT is set in the request).

+Orthogonal to this, is the decision to poke kswapd to free some zone pages.

+That decision is not hysteresis based, and is done when the number of free

+pages is below watermark[WMARK_LOW]; in which case zone_wake_kswapd is also set.

diff --git a/Documentation/vm/page-types.c b/Documentation/vm/page-types.c
new file mode 100644
index 000000000000..0833f44ba16b
--- /dev/null
+++ b/Documentation/vm/page-types.c

+/* [48-] take some arbitrary free slots for expanding overloaded flags

+#define BITS_COMPOUND (BIT(COMPOUND_HEAD) | BIT(COMPOUND_TAIL))

+static uint64_t kpageflags_buf[KPF_BYTES * PAGES_BATCH];

+ for (i = 0, j = 0; i < ARRAY_SIZE(page_flag_names); i++) {

+ for (i = 0, n = 0; i < ARRAY_SIZE(page_flag_names); i++) {

+void show_page_range(unsigned long offset, uint64_t flags)

+ /* PG_reclaim is overloaded as PG_readahead in the read path */

+ if ((flags & (BIT(RECLAIM) | BIT(WRITEBACK))) == BIT(RECLAIM))

+ /* Explicitly reserve slot 0 for flags 0: the following logic

+ * cannot distinguish an unoccupied slot from slot (flags==0).

+ n = read(kpageflags_fd, kpageflags_buf, batch * KPF_BYTES);

+ for (i = 0, j = 0; i < ARRAY_SIZE(page_flag_names); i++) {

+void add_addr_range(unsigned long offset, unsigned long size)

diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt
index ce72c0fe6177..600a304a828c 100644
--- a/Documentation/vm/pagemap.txt
+++ b/Documentation/vm/pagemap.txt

value for each virtual page, containing the following data (from

* /proc/kpageflags. This file contains a 64-bit set of flags for each

- The flags are (from fs/proc/proc_misc, above kpageflags_read):

+ The flags are (from fs/proc/page.c, above kpageflags_read):

@@ -49,6 +49,68 @@ There are three components to pagemap:

+ page is being locked for exclusive access, eg. by undergoing read/write IO

+ page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator

+ When compound page is used, SLUB/SLQB will only set this flag on the head

+ a free memory block managed by the buddy system allocator

+ The buddy system organizes free memory in blocks of various orders.

+ An order N block has 2^N physically contiguous pages, with the BUDDY flag

+ A compound page with order N consists of 2^N physically contiguous pages.

+ A compound page with order 2 takes the form of "HTTT", where H donates its

+ head page and T donates its tail page(s). The major consumers of compound

+ pages are hugeTLB pages (Documentation/vm/hugetlbpage.txt), the SLUB etc.

+ memory allocators and various device drivers. However in this interface,

+ ie. for file backed page: (in-memory data revision >= on-disk one)

+ 4. DIRTY page has been written to, hence contains new data

+ ie. for file backed page: (in-memory data revision > on-disk one)

+18. UNEVICTABLE page is in the unevictable (non-)LRU list

+ It is somehow pinned and not a candidate for LRU page reclaims,

+ eg. ramfs pages, shmctl(SHM_LOCK) and mlock() memory segments

+ 2. REFERENCED page has been referenced since last LRU list enqueue/requeue

+ 9. RECLAIM page will be reclaimed soon after its pageout IO completed

+12. ANON a memory mapped page that is not part of a file

+13. SWAPCACHE page is mapped to swap space, ie. has an associated swap entry

+The page-types tool in this directory can be used to query the above flags.

diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index e0203662f9e9..8da3a795083f 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt

@@ -50,6 +50,10 @@ Protocol 2.08: (Kernel 2.6.26) Added crc32 checksum and ELF format

Protocol 2.09: (Kernel 2.6.26) Added a field of 64-bit physical

+Protocol 2.10: (Kernel 2.6.31) Added a protocol for relaxed alignment

The traditional memory map for the kernel loader, used for Image or

021C/4 2.00+ ramdisk_size initrd size (set by boot loader)

0220/4 2.00+ bootsect_kludge DO NOT USE - for bootsect.S use only

+0226/1 2.02+(3 ext_loader_ver Extended boot loader version

0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line

0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel

0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not

+0235/1 2.10+ min_alignment Minimum alignment, as a power of two

0238/4 2.06+ cmdline_size Maximum size of the kernel command line

0250/8 2.09+ setup_data 64-bit physical pointer to linked list

+0260/4 2.10+ init_size Linear memory required during initialization

(1) For backwards compatibility, if the setup_sects field contains 0, the

field are unusable, which means the size of a bzImage kernel

+(3) Ignored, but safe to set, for boot protocols 2.02-2.09.

If the "HdrS" (0x53726448) magic number is not found at offset 0x202,

the boot protocol version is "old". Loading an old kernel, the

0xTV here, where T is an identifier for the boot loader and V is

+ For boot loader IDs above T = 0xD, write T = 0xE to this field and

+ write the extended ID minus 0x10 to the ext_loader_type field.

+ Similarly, the ext_loader_ver field can be used to provide more than

Please contact <hpa@zytor.com> if you need a bootloader ID

Set this field to the offset (from the beginning of the real-mode

+ This field is used as an extension of the version number in the

+ type_of_loader field. The total version number is considered to be

+ The use of this field is boot loader specific. If not written, it

+ Kernels prior to 2.6.31 did not recognize this field, but it is safe

+Type: write (obligatory if (type_of_loader & 0xf0) == 0xe0)

+ This field is used as an extension of the type number in

+ type_of_loader field. If the type in type_of_loader is 0xE, then

+ This field is ignored if the type in type_of_loader is not 0xE.

+ Kernels prior to 2.6.31 did not recognize this field, but it is safe

+ Alignment unit required by the kernel (if relocatable_kernel is

+ true.) A relocatable kernel that is loaded at an alignment

+ incompatible with the value in this field will be realigned during

- Alignment unit required by the kernel (if relocatable_kernel is true.)

+ Starting with protocol version 2.10, this reflects the kernel

+ alignment preferred for optimal performance; it is possible for the

+ loader to modify this field to permit a lesser alignment. See the

After loading, the boot loader must set the code32_start field to

+ This field, if nonzero, indicates as a power of two the minimum

+ alignment required, as opposed to preferred, by the kernel to boot.

+ If a boot loader makes use of this field, it should update the

+ kernel_alignment field with the alignment unit desired; typically:

+ There may be a considerable performance cost with an excessively

+ misaligned kernel. Therefore, a loader should typically try each

+ power-of-two alignment from kernel_alignment down to this alignment.

sure to consider the case where the linked list already contains

+ This field, if nonzero, represents a preferred load address for the

+ kernel. A relocating bootloader should attempt to load at this

+ A non-relocatable kernel will unconditionally move itself and to run

+ This field indicates the amount of linear contiguous memory starting

+ at the kernel runtime start address that the kernel needs before it

+ is capable of examining its memory map. This is not the same thing

+ as the total amount of memory the kernel needs to boot, but it can

+ be used by a relocating boot loader to help select a safe load

+ The kernel runtime start address is determined by the following algorithm:

+ runtime_start = align_up(load_address, kernel_alignment)

diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt
index 34c13040a718..29a6ff8bc7d3 100644
--- a/Documentation/x86/x86_64/boot-options.txt
+++ b/Documentation/x86/x86_64/boot-options.txt

@@ -5,21 +5,51 @@ only the AMD64 specific ones are listed here.

- mce=bootlog Enable logging of machine checks left over from booting.

- Disabled by default on AMD because some BIOS leave bogus ones.

- If your BIOS doesn't do that it's a good idea to enable though

- to make sure you log even machine check events that result

- in a reboot. On Intel systems it is enabled by default.

+ Please see Documentation/x86/x86_64/machinecheck for sysfs runtime tunables.

+ not recommended, but it might be handy if your hardware

+ Note that you'll get more problems without CMCI than with

+ Don't make logs for corrected errors. All events reported

+ This option will be useful if you have no interest in any

+ Disable features for corrected errors, e.g. polling timer

+ and CMCI. All events reported as corrected are not cleared

+ Usually this disablement is not recommended, however if

+ (e.g. BIOS or hardware monitoring applications), conflicting

+ with OS's error handling, and you cannot deactivate the agent,

+ Enable logging of machine checks left over from booting.

+ Disabled by default on AMD because some BIOS leave bogus ones.

+ If your BIOS doesn't do that it's a good idea to enable though

+ to make sure you log even machine check events that result

+ in a reboot. On Intel systems it is enabled by default.

0: always panic on uncorrected errors, log corrected errors

1: panic or SIGBUS on uncorrected errors, log corrected errors

2: SIGBUS or log uncorrected errors, log corrected errors

3: never panic or SIGBUS, log all errors (for testing only)

+ Sets the time in us to wait for other CPUs on machine checks. 0

- Only allow hotadd memory to preallocate page structures upto

diff --git a/Documentation/x86/x86_64/machinecheck b/Documentation/x86/x86_64/machinecheck
index a05e58e7b159..b1fb30273286 100644
--- a/Documentation/x86/x86_64/machinecheck
+++ b/Documentation/x86/x86_64/machinecheck

the polling interval. When the poller stops finding MCEs, it

triggers an exponential backoff (poll less often) on the polling

interval. The check_interval variable is both the initial and

+ maximum polling interval. 0 means no polling for corrected machine

+ check errors (but some corrected errors might be still reported

Tolerance level. When a machine check exception occurs for a non

This is an alternative to running mcelog regularly from cron

+ How long to wait for the other CPUs to machine check too on a

TBD document entries for AMD threshold interrupt configuration

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 29b52b14d0b4..d6498e3cd713 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt

@@ -6,10 +6,11 @@ Virtual memory map with 4 level page tables:

0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm

ffff800000000000 - ffff80ffffffffff (=40 bits) guard hole

-ffff880000000000 - ffffc0ffffffffff (=57 TB) direct mapping of all phys. memory

-ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space

-ffffe20000000000 - ffffe2ffffffffff (=40 bits) virtual memory map (1TB)

+ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory

+ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space

+ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)

ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0

ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space

diff --git a/MAINTAINERS b/MAINTAINERS
index 2b349ba4add4..fb94addb34de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS

@@ -36,6 +36,12 @@ trivial patch so apply some common sense.

(scripts/checkpatch.pl) to catch trival style violations.

+ PLEASE CC: the maintainers and mailing lists that are generated

+ by scripts/get_maintainer.pl. The results returned by the

+ script will be best if you have git installed and are making

+ your changes in a branch derived from Linus' latest git tree.

PLEASE try to include any credit lines you want added with the

patch. It avoids people being missed off by mistake and makes

-T: SCM tree type and location. Type is one of: git, hg, quilt.

+T: SCM tree type and location. Type is one of: git, hg, quilt, stgit.

L: linux-geode@lists.infradead.org (moderated for non-subscribers)

@@ -487,7 +495,7 @@ AOA (Apple Onboard Audio) ALSA DRIVER

+L: alsa-devel@alsa-project.org (moderated for non-subscribers)

L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)

-L: uclinux-dist-devel@blackfin.uclinux.org (subscribers-only)

@@ -1182,7 +1200,6 @@ F: drivers/i2c/busses/i2c-bfin-twi.c

T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

+L: alsa-devel@alsa-project.org (moderated for non-subscribers)

@@ -1532,6 +1560,13 @@ W: http://www.fi.muni.cz/~kas/cosa/

T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/

+L: bluesmoke-devel@lists.sourceforge.net (moderated for non-subscribers)

L: bluesmoke-devel@lists.sourceforge.net (moderated for non-subscribers)

@@ -2077,6 +2116,15 @@ W: http://sourceforge.net/projects/lpfcxxxx

+L: alsa-devel@alsa-project.org (moderated for non-subscribers)

@@ -2714,7 +2756,6 @@ F: drivers/i2c/busses/i2c-tiny-usb.c

@@ -2799,6 +2840,18 @@ L: linux1394-devel@lists.sourceforge.net

+T: git git://git.kernel.org/pub/scm/linux/kernel/git/lumag/lowpan.git

@@ -2878,7 +2932,6 @@ F: arch/x86/kernel/microcode_intel.c

+T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/irda-2.6.git

W: http://ftp.kernel.org/pub/linux/kernel/people/horms/kexec-tools/

T: git git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-lockdep.git

@@ -3576,7 +3641,6 @@ L: linux-m32r-ja@ml.linux-m32r.org (in Japanese)

@@ -3829,7 +3886,6 @@ F: drivers/platform/x86/msi-laptop.c

T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git

MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM

T: git git://git.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs-2.6.git

+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git

+L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)

@@ -4335,7 +4448,6 @@ F: Documentation/powerpc/eeh-pci-error-recovery.txt

T: git git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6.git

W: ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-kernel

L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)

T: git git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git

L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)

T: git git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git

+L: rds-devel@oss.oracle.com (moderated for non-subscribers)

L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)

T: git git://www.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6.git

L: selinux@tycho.nsa.gov (subscribers-only, general discussion)

T: git git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6.git

+L: alsa-devel@alsa-project.org (moderated for non-subscribers)

T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git

+T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git

+L: alsa-devel@alsa-project.org (moderated for non-subscribers)

T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/

L: tomoyo-users-en@lists.sourceforge.jp (subscribers-only, for developers and users in English)

L: tomoyo-dev@lists.sourceforge.jp (subscribers-only, for developers in Japanese)

L: tomoyo-users@lists.sourceforge.jp (subscribers-only, for users in Japanese)

T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git

T: git git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git

T: git git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

diff --git a/Makefile b/Makefile
index b57e1f539e83..ea63667617f3 100644
--- a/Makefile
+++ b/Makefile

# To put more focus on warnings, be less verbose as default

# See the file "Documentation/sparse.txt" for more details, including

# kbuild supports saving output files in a separate directory.

# To locate output files in a separate directory two syntaxes are supported.

# Do we want to locate output files in a separate directory?

# That's our default target when none is given on the command line

KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})

diff --git a/README b/README
index d6c6c742c1d7..737838fe73cc 100644
--- a/README
+++ b/README

"make defconfig" Create a ./.config file by using the default

diff --git a/arch/alpha/include/asm/8253pit.h b/arch/alpha/include/asm/8253pit.h
index fef5c1450e47..a71c9c1455a7 100644
--- a/arch/alpha/include/asm/8253pit.h
+++ b/arch/alpha/include/asm/8253pit.h

diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/atomic.h
index 62b363584b2b..610dff44d94b 100644
--- a/arch/alpha/include/asm/atomic.h
+++ b/arch/alpha/include/asm/atomic.h

@@ -256,5 +256,5 @@ static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)

diff --git a/arch/alpha/include/asm/bitsperlong.h b/arch/alpha/include/asm/bitsperlong.h
new file mode 100644
index 000000000000..ad57f7868203
--- /dev/null
+++ b/arch/alpha/include/asm/bitsperlong.h

diff --git a/arch/alpha/include/asm/errno.h b/arch/alpha/include/asm/errno.h
index 69e2655249d2..98099bda9370 100644
--- a/arch/alpha/include/asm/errno.h
+++ b/arch/alpha/include/asm/errno.h

+#define ERFKILL 138 /* Operation not possible due to RF-kill */

diff --git a/arch/alpha/include/asm/kmap_types.h b/arch/alpha/include/asm/kmap_types.h
index 3e6735a34c57..a8d4ec8ea4b6 100644
--- a/arch/alpha/include/asm/kmap_types.h
+++ b/arch/alpha/include/asm/kmap_types.h

diff --git a/arch/alpha/include/asm/page.h b/arch/alpha/include/asm/page.h
index 0995f9d13417..07af062544fb 100644
--- a/arch/alpha/include/asm/page.h
+++ b/arch/alpha/include/asm/page.h

diff --git a/arch/alpha/include/asm/signal.h b/arch/alpha/include/asm/signal.h
index 13c2305d35ef..a9388300abb1 100644
--- a/arch/alpha/include/asm/signal.h
+++ b/arch/alpha/include/asm/signal.h

diff --git a/arch/alpha/include/asm/suspend.h b/arch/alpha/include/asm/suspend.h
deleted file mode 100644
index c7042d575851..000000000000
--- a/arch/alpha/include/asm/suspend.h
+++ /dev/null

diff --git a/arch/alpha/include/asm/types.h b/arch/alpha/include/asm/types.h
index f072f344497e..bd621ecd1eb3 100644
--- a/arch/alpha/include/asm/types.h
+++ b/arch/alpha/include/asm/types.h

* These aren't exported outside the kernel to avoid name space clashes

diff --git a/arch/alpha/kernel/init_task.c b/arch/alpha/kernel/init_task.c
index c2938e574a40..19b86328ffd7 100644
--- a/arch/alpha/kernel/init_task.c
+++ b/arch/alpha/kernel/init_task.c

static struct signal_struct init_signals = INIT_SIGNALS(init_signals);

static struct sighand_struct init_sighand = INIT_SIGHAND(init_sighand);

diff --git a/arch/alpha/kernel/irq_alpha.c b/arch/alpha/kernel/irq_alpha.c
index 67c19f8a9944..38c805dfc544 100644
--- a/arch/alpha/kernel/irq_alpha.c
+++ b/arch/alpha/kernel/irq_alpha.c

diff --git a/arch/alpha/kernel/irq_i8259.c b/arch/alpha/kernel/irq_i8259.c
index 9405bee9894e..50bfec9b588f 100644
--- a/arch/alpha/kernel/irq_i8259.c
+++ b/arch/alpha/kernel/irq_i8259.c

diff --git a/arch/alpha/kernel/irq_impl.h b/arch/alpha/kernel/irq_impl.h
index cc9a8a7aa279..b63ccd7386f1 100644
--- a/arch/alpha/kernel/irq_impl.h
+++ b/arch/alpha/kernel/irq_impl.h

@@ -36,7 +36,7 @@ extern void i8259a_disable_irq(unsigned int);

diff --git a/arch/alpha/kernel/irq_pyxis.c b/arch/alpha/kernel/irq_pyxis.c
index d53edbccbfe5..69199a76ec4a 100644
--- a/arch/alpha/kernel/irq_pyxis.c
+++ b/arch/alpha/kernel/irq_pyxis.c

@@ -70,7 +70,7 @@ pyxis_mask_and_ack_irq(unsigned int irq)

diff --git a/arch/alpha/kernel/irq_srm.c b/arch/alpha/kernel/irq_srm.c
index a03fbca4940e..85229369a1f8 100644
--- a/arch/alpha/kernel/irq_srm.c
+++ b/arch/alpha/kernel/irq_srm.c

/* Handle interrupts from the SRM, assuming no additional weirdness. */

diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index 42ee05981e71..9a3334ae282e 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c

@@ -371,8 +371,6 @@ SYSCALL_DEFINE4(osf_mount, unsigned long, typenr, char __user *, path,

@@ -392,7 +390,6 @@ SYSCALL_DEFINE4(osf_mount, unsigned long, typenr, char __user *, path,

diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c
index 80df86cd746b..d2634e4476b4 100644
--- a/arch/alpha/kernel/setup.c
+++ b/arch/alpha/kernel/setup.c

diff --git a/arch/alpha/kernel/sys_alcor.c b/arch/alpha/kernel/sys_alcor.c
index e53a1e1c2f21..382035ef7394 100644
--- a/arch/alpha/kernel/sys_alcor.c
+++ b/arch/alpha/kernel/sys_alcor.c

diff --git a/arch/alpha/kernel/sys_cabriolet.c b/arch/alpha/kernel/sys_cabriolet.c
index ace475c124f6..ed349436732b 100644
--- a/arch/alpha/kernel/sys_cabriolet.c
+++ b/arch/alpha/kernel/sys_cabriolet.c

diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c
index 9c9d1fd4155f..46e70ece5176 100644
--- a/arch/alpha/kernel/sys_dp264.c
+++ b/arch/alpha/kernel/sys_dp264.c

@@ -176,25 +176,29 @@ cpu_set_irq_affinity(unsigned int irq, cpumask_t affinity)

dp264_set_affinity(unsigned int irq, const struct cpumask *affinity)

clipper_set_affinity(unsigned int irq, const struct cpumask *affinity)

@@ -205,7 +209,7 @@ static struct hw_interrupt_type dp264_irq_type = {

@@ -294,7 +298,7 @@ clipper_srm_device_interrupt(unsigned long vector)

-init_tsunami_irqs(struct hw_interrupt_type * ops, int imin, int imax)

+init_tsunami_irqs(struct irq_chip * ops, int imin, int imax)

diff --git a/arch/alpha/kernel/sys_eb64p.c b/arch/alpha/kernel/sys_eb64p.c
index 9c5a306dc0ee..660c23ef661f 100644
--- a/arch/alpha/kernel/sys_eb64p.c
+++ b/arch/alpha/kernel/sys_eb64p.c

diff --git a/arch/alpha/kernel/sys_eiger.c b/arch/alpha/kernel/sys_eiger.c
index baf60f36cbd7..b99ea488d844 100644
--- a/arch/alpha/kernel/sys_eiger.c
+++ b/arch/alpha/kernel/sys_eiger.c

diff --git a/arch/alpha/kernel/sys_jensen.c b/arch/alpha/kernel/sys_jensen.c
index 2b5caf3d9b15..ef0b83a070ac 100644
--- a/arch/alpha/kernel/sys_jensen.c
+++ b/arch/alpha/kernel/sys_jensen.c

-static struct hw_interrupt_type jensen_local_irq_type = {

diff --git a/arch/alpha/kernel/sys_marvel.c b/arch/alpha/kernel/sys_marvel.c
index c5a1a2438c67..bbfc4f20ca72 100644
--- a/arch/alpha/kernel/sys_marvel.c
+++ b/arch/alpha/kernel/sys_marvel.c

@@ -169,7 +169,7 @@ marvel_irq_noop_return(unsigned int irq)

-static struct hw_interrupt_type marvel_legacy_irq_type = {

@@ -179,7 +179,7 @@ static struct hw_interrupt_type marvel_legacy_irq_type = {

@@ -189,7 +189,7 @@ static struct hw_interrupt_type io7_lsi_irq_type = {

@@ -273,8 +273,8 @@ init_one_io7_msi(struct io7 *io7, unsigned int which, unsigned int where)

diff --git a/arch/alpha/kernel/sys_mikasa.c b/arch/alpha/kernel/sys_mikasa.c
index 8d3e9429c5ee..4e366641a08e 100644
--- a/arch/alpha/kernel/sys_mikasa.c
+++ b/arch/alpha/kernel/sys_mikasa.c

diff --git a/arch/alpha/kernel/sys_noritake.c b/arch/alpha/kernel/sys_noritake.c
index 538876b62449..35753a173bac 100644
--- a/arch/alpha/kernel/sys_noritake.c
+++ b/arch/alpha/kernel/sys_noritake.c

diff --git a/arch/alpha/kernel/sys_rawhide.c b/arch/alpha/kernel/sys_rawhide.c
index 672cb2df53df..f3aec7e085c8 100644
--- a/arch/alpha/kernel/sys_rawhide.c
+++ b/arch/alpha/kernel/sys_rawhide.c

diff --git a/arch/alpha/kernel/sys_ruffian.c b/arch/alpha/kernel/sys_ruffian.c
index f15a329b6011..d9f9cfeb9931 100644
--- a/arch/alpha/kernel/sys_ruffian.c
+++ b/arch/alpha/kernel/sys_ruffian.c

diff --git a/arch/alpha/kernel/sys_rx164.c b/arch/alpha/kernel/sys_rx164.c
index ce1faa6f1df1..fc9246373452 100644
--- a/arch/alpha/kernel/sys_rx164.c
+++ b/arch/alpha/kernel/sys_rx164.c

diff --git a/arch/alpha/kernel/sys_sable.c b/arch/alpha/kernel/sys_sable.c
index 9e263256a42d..426eb6906d01 100644
--- a/arch/alpha/kernel/sys_sable.c
+++ b/arch/alpha/kernel/sys_sable.c

@@ -501,7 +501,7 @@ sable_lynx_mask_and_ack_irq(unsigned int irq)

diff --git a/arch/alpha/kernel/sys_takara.c b/arch/alpha/kernel/sys_takara.c
index 9bd9a31450c6..830318c21661 100644
--- a/arch/alpha/kernel/sys_takara.c
+++ b/arch/alpha/kernel/sys_takara.c

diff --git a/arch/alpha/kernel/sys_titan.c b/arch/alpha/kernel/sys_titan.c
index 27f840a4ad3d..88978fc60f83 100644
--- a/arch/alpha/kernel/sys_titan.c
+++ b/arch/alpha/kernel/sys_titan.c

@@ -157,13 +157,15 @@ titan_cpu_set_irq_affinity(unsigned int irq, cpumask_t affinity)

titan_set_irq_affinity(unsigned int irq, const struct cpumask *affinity)

@@ -183,7 +185,7 @@ titan_srm_device_interrupt(unsigned long vector)

-init_titan_irqs(struct hw_interrupt_type * ops, int imin, int imax)

+init_titan_irqs(struct irq_chip * ops, int imin, int imax)

@@ -192,7 +194,7 @@ init_titan_irqs(struct hw_interrupt_type * ops, int imin, int imax)

diff --git a/arch/alpha/kernel/sys_wildfire.c b/arch/alpha/kernel/sys_wildfire.c
index 42c3eede4d09..e91b4c3838a8 100644
--- a/arch/alpha/kernel/sys_wildfire.c
+++ b/arch/alpha/kernel/sys_wildfire.c

diff --git a/arch/alpha/mm/extable.c b/arch/alpha/mm/extable.c
index 62dc379d301a..813c9b63c0e1 100644
--- a/arch/alpha/mm/extable.c
+++ b/arch/alpha/mm/extable.c

@@ -48,6 +48,27 @@ void sort_extable(struct exception_table_entry *start,

+ * Any entry referring to the module init will be at the beginning or

+ within_module_init(ex_to_addr(&m->extable[m->num_exentries-1]),

search_extable(const struct exception_table_entry *first,

diff --git a/arch/alpha/mm/numa.c b/arch/alpha/mm/numa.c
index a13de49d1265..0eab55749423 100644
--- a/arch/alpha/mm/numa.c
+++ b/arch/alpha/mm/numa.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e60ec54df334..29475101a7b3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig

This enables support for the Cirrus EP93xx series of CPUs.

("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.

+ Support for Freescale MXC/iMX-based family of processors

This enables support for systems based on the Hynix HMS720x

- Support for Motorola's i.MX family of processors (MX1, MXL).

- Support for Micrel/Kendin KS8695 "Centaur" (ARM922T) based

- Say Y here if you intend to run this kernel on a NetSilicon NS9xxx

- <http://www.digi.com/products/microprocessors/index.jsp>

- Support for Freescale MXC/iMX-based family of processors

+ Support for Micrel/Kendin KS8695 "Centaur" (ARM922T) based

+ Say Y here if you intend to run this kernel on a NetSilicon NS9xxx

+ <http://www.digi.com/products/microprocessors/index.jsp>

+ Support for Nuvoton (Winbond logic dept.) ARM9 processor,You

+ can login www.mcuos.com or www.nuvoton.com to know more.

Support for Intel/Marvell's PXA2xx/PXA3xx processor line.

+ Support for Qualcomm MSM7K based systems. This runs on the ARM11

+ apps processor of the MSM7K and depends on a shared memory

+ interface to the ARM9 modem processor which runs the baseband stack

+ and controls some vital subsystems (clock and power control, etc).

- Support for Qualcomm MSM7K based systems. This runs on the ARM11

- apps processor of the MSM7K and depends on a shared memory

- interface to the ARM9 modem processor which runs the baseband stack

- and controls some vital subsystems (clock and power control, etc).

- Support for Nuvoton (Winbond logic dept.) ARM9 processor,You

- can login www.mcuos.com or www.nuvoton.com to know more.

@@ -680,9 +700,9 @@ source "arch/arm/mach-s3c6400/Kconfig"

@@ -706,6 +726,8 @@ source "arch/arm/mach-ks8695/Kconfig"

- depends on EXPERIMENTAL && (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP)

+ depends on EXPERIMENTAL && (REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP ||\

+ MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4)

This enables support for systems with more than one CPU. If you have

a system with only one CPU, like most personal computers, say N. If

+ This option enables support for the ARM system coherency unit

+ This options enables support for the ARM timer and watchdog unit

- depends on SMP && (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || REALVIEW_EB_A9MP)

+ depends on SMP && (REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || \

Enable support for local timers on SMP platforms, rather then the

legacy IPI broadcast method. Local timers allows the system

UNPREDICTABLE (in fact it can be predicted that it won't work

to provide useful information about your current system status.

correct operation of some network protocols. With an IP-only

+ bool "Use kernel mem{cpy,set}() for {copy_to,clear}_user() (EXPERIMENTAL)"

+ Implement faster copy_to_user and clear_user methods for CPU

+ cores where a 8-word STM instruction give significantly higher

+ memory write throughput than a sequence of individual 32bit stores.

+ A possible side effect is a slight increase in scheduling latency

+ between threads sharing the same address space if they invoke

+ However, if the CPU data cache is using a write-allocate mode,

+ this option is unlikely to provide any performance gain.

-if (ARCH_SA1100 || ARCH_INTEGRATOR || ARCH_OMAP || ARCH_IMX || ARCH_PXA)

+if (ARCH_SA1100 || ARCH_INTEGRATOR || ARCH_OMAP || ARCH_PXA)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e84729bf13d4..c877d6df23d1 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile

OBJCOPYFLAGS :=-O binary -R .note -R .note.gnu.build-id -R .comment -S

head-y := arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o

# SA1111 DMA bug: we don't want the kernel to live in precious DMA-able memory

- machine-$(CONFIG_ARCH_S3C2410) := s3c2410 s3c2400 s3c2412 s3c2440 s3c2442 s3c2443

+# Machine directory name. This list is sorted alphanumerically

+machine-$(CONFIG_ARCH_S3C2410) := s3c2410 s3c2400 s3c2412 s3c2440 s3c2442 s3c2443

+# Platform directory name. This list is sorted alphanumerically

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index fbe5eef1f6c9..ce39dc540085 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile

# linker symbols. We only define initrd_phys and params_phys if the

# machine class defined the corresponding makefile variable.

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index b371fba1b954..01d49be3b2ca 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S

orr r0, r0, #0x5000 @ I-cache enable, RR cache replacement

diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index a2cd9beaf37d..4efbb9df0444 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig

+ The maximum number of VICs available in the system, for

diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 7cb7961d81cb..76be7ff2a7ca 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile

diff --git a/arch/arm/common/clkdev.c b/arch/arm/common/clkdev.c
index 5589444ff437..f37afd9422f3 100644
--- a/arch/arm/common/clkdev.c
+++ b/arch/arm/common/clkdev.c

@@ -135,6 +135,24 @@ struct clk_lookup *clkdev_alloc(struct clk *clk, const char *con_id,

+int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,

diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index c6884ba1d5ed..664c7b8b1ba8 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c

@@ -109,7 +109,7 @@ static void gic_unmask_irq(unsigned int irq)

-static void gic_set_cpu(unsigned int irq, const struct cpumask *mask_val)

+static int gic_set_cpu(unsigned int irq, const struct cpumask *mask_val)

void __iomem *reg = gic_dist_base(irq) + GIC_DIST_TARGET + (gic_irq(irq) & ~3);

@@ -122,6 +122,8 @@ static void gic_set_cpu(unsigned int irq, const struct cpumask *mask_val)

@@ -253,9 +255,9 @@ void __cpuinit gic_cpu_init(unsigned int gic_nr, void __iomem *base)

-void gic_raise_softirq(cpumask_t cpumask, unsigned int irq)

+void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)

writel(map << 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT);

diff --git a/arch/arm/common/sharpsl_pm.c b/arch/arm/common/sharpsl_pm.c
deleted file mode 100644
index 140f1d721d50..000000000000
--- a/arch/arm/common/sharpsl_pm.c
+++ /dev/null

- * Battery and Power Management code for the Sharp SL-C7xx and SL-Cxx00

- * This program is free software; you can redistribute it and/or modify

- * it under the terms of the GNU General Public License version 2 as

-#define SHARPSL_CHARGE_ON_TIME_INTERVAL (msecs_to_jiffies(1*60*1000)) /* 1 min */

-#define SHARPSL_CHARGE_FINISH_TIME (msecs_to_jiffies(10*60*1000)) /* 10 min */

-#define SHARPSL_BATCHK_TIME (msecs_to_jiffies(15*1000)) /* 15 sec */

-#define SHARPSL_BATCHK_TIME_SUSPEND (60*10) /* 10 min */

-#define SHARPSL_CHECK_BATTERY_WAIT_TIME_TEMP 10 /* 10 msec */

-#define SHARPSL_CHECK_BATTERY_WAIT_TIME_VOLT 10 /* 10 msec */

-#define SHARPSL_CHECK_BATTERY_WAIT_TIME_ACIN 10 /* 10 msec */

-static void sharpsl_charge_toggle(struct work_struct *private_);

-static void sharpsl_battery_thread(struct work_struct *private_);

-DECLARE_DELAYED_WORK(toggle_charger, sharpsl_charge_toggle);

-DECLARE_DELAYED_WORK(sharpsl_bat, sharpsl_battery_thread);

- int bl_status = sharpsl_pm.machinfo->backlight_get_status ? sharpsl_pm.machinfo->backlight_get_status() : 0;

- thresh = bl_status ? sharpsl_pm.machinfo->bat_levels_acin_bl : sharpsl_pm.machinfo->bat_levels_acin;

- thresh = bl_status ? sharpsl_pm.machinfo->bat_levels_noac_bl : sharpsl_pm.machinfo->bat_levels_noac;

- schedule_delayed_work(&sharpsl_bat, msecs_to_jiffies(125));

-static void sharpsl_battery_thread(struct work_struct *private_)

- sharpsl_pm.battstat.ac_status = (sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_ACIN) ? APM_AC_ONLINE : APM_AC_OFFLINE);

- /* Corgi cannot confirm when battery fully charged so periodically kick! */

- if (!sharpsl_pm.machinfo->batfull_irq && (sharpsl_pm.charge_mode == CHRG_ON)

- && time_after(jiffies, sharpsl_pm.charge_start_time + SHARPSL_CHARGE_ON_TIME_INTERVAL))

- voltage = sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT);

- voltage = sharpsl_pm.machinfo->bat_levels_noac[0].voltage;

- dev_warn(sharpsl_pm.dev, "Warning: Cannot read main battery!\n");

- /* At low battery voltages, the voltage has a tendency to start

- if ((sharpsl_pm.battstat.ac_status == APM_AC_ONLINE) || (apm_status == APM_BATTERY_STATUS_HIGH) || percent <= sharpsl_pm.battstat.mainbat_percent) {

- dev_dbg(sharpsl_pm.dev, "Battery: voltage: %d, status: %d, percentage: %d, time: %ld\n", voltage,

- sharpsl_pm.battstat.mainbat_status, sharpsl_pm.battstat.mainbat_percent, jiffies);

- /* If battery is low. limit backlight intensity to save power. */

- && ((sharpsl_pm.battstat.mainbat_status == APM_BATTERY_STATUS_LOW) ||

- (sharpsl_pm.battstat.mainbat_status == APM_BATTERY_STATUS_CRITICAL))) {

- && (sharpsl_pm.battstat.mainbat_status == APM_BATTERY_STATUS_CRITICAL)

- schedule_delayed_work(&sharpsl_bat, SHARPSL_BATCHK_TIME);

- led_trigger_event(sharpsl_charge_led_trigger, LED_FULL);

- led_trigger_event(sharpsl_charge_led_trigger, LED_OFF);

- schedule_delayed_work(&toggle_charger, msecs_to_jiffies(250));

- schedule_delayed_work(&sharpsl_bat, msecs_to_jiffies(500));

-static void sharpsl_charge_toggle(struct work_struct *private_)

- dev_dbg(sharpsl_pm.dev, "Toogling Charger at time: %lx\n", jiffies);

- if (!sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_ACIN)) {

- } else if ((sharpsl_check_battery_temp() < 0) || (sharpsl_ac_check() < 0)) {

- int acin = sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_ACIN);

- /* Must be a smaller delay than the chrg_full_isr below */

- mod_timer(&sharpsl_pm.ac_timer, jiffies + msecs_to_jiffies(250));

- dev_dbg(sharpsl_pm.dev, "Charge Full at time: %lx\n", jiffies);

- if (!sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_ACIN)) {

- dev_dbg(sharpsl_pm.dev, "Charge Full: AC removed - stop charging!\n");

- dev_dbg(sharpsl_pm.dev, "Charge Full: Count too low\n");

- } else if (time_after(jiffies, sharpsl_pm.charge_start_time + SHARPSL_CHARGE_FINISH_TIME)) {

- dev_dbg(sharpsl_pm.dev, "Charge Full: Interrupt generated too slowly - retry.\n");

- dev_dbg(sharpsl_pm.dev, "Charge Full: Charging Finished\n");

-/* Charging Finished Interrupt (Not present on Corgi) */

-/* Can trigger at the same time as an AC status change so

-irqreturn_t sharpsl_chrg_full_isr(int irq, void *dev_id)

- mod_timer(&sharpsl_pm.chrg_full_timer, jiffies + msecs_to_jiffies(500));

- if (!sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_LOCK)) {

- dev_err(sharpsl_pm.dev, "Battery now Unlocked! Suspending.\n");

- if (!sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_FATAL)) {

- dev_err(sharpsl_pm.dev, "Fatal Batt Error! Suspending.\n");

- if (!(sharpsl_pm.flags & SHARPSL_APM_QUEUED) && is_fatal) {

- if (sharpsl_pm.battstat.mainbat_status != APM_BATTERY_STATUS_HIGH) {

- * Take an array of 5 integers, remove the maximum and minimum values

- dev_dbg(sharpsl_pm.dev, "Average: %d from values: %d, %d, %d, %d, %d\n", sum/3, val[0], val[1], val[2], val[3], val[4]);

- buff[i] = sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_TEMP);

- printk(KERN_WARNING "Not charging: temperature out of limits.\n");

- buff[i] = sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT);

- buff[i] = sharpsl_pm.machinfo->read_devdata(SHARPSL_ACIN_VOLT);

- if ((temp > sharpsl_pm.machinfo->charge_acin_high) || (temp < sharpsl_pm.machinfo->charge_acin_low)) {

-static int sharpsl_pm_suspend(struct platform_device *pdev, pm_message_t state)

-static int sharpsl_pm_resume(struct platform_device *pdev)

- /* Clear the reset source indicators as they break the bootloader upon reboot */

-static void corgi_goto_sleep(unsigned long alarm_time, unsigned int alarm_enable, suspend_state_t state)

- dev_dbg(sharpsl_pm.dev, "Offline Charge Activate = %d\n",sharpsl_pm.flags & SHARPSL_DO_OFFLINE_CHRG);

- if ((sharpsl_pm.flags & SHARPSL_DO_OFFLINE_CHRG) && (sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_ACIN))) {

- dev_dbg(sharpsl_pm.dev, "Activating Offline Charger...\n");

- if ((sharpsl_pm.charge_mode == CHRG_ON) && ((alarm_enable && ((alarm_time - RCNR) > (SHARPSL_BATCHK_TIME_SUSPEND + 30))) || !alarm_enable)) {

- dev_dbg(sharpsl_pm.dev, "Charging alarm at: %08x\n",RTAR);

- dev_dbg(sharpsl_pm.dev, "Corgi woken up from suspend: %08x\n",PEDR);

-static int corgi_enter_suspend(unsigned long alarm_time, unsigned int alarm_enable, suspend_state_t state)

- if (!sharpsl_pm.machinfo->should_wakeup(!(sharpsl_pm.flags & SHARPSL_ALARM_ACTIVE) && alarm_enable) )

- dev_dbg(sharpsl_pm.dev, "No user triggered wakeup events and not charging. Strange. Suspend.\n");

- dev_dbg(sharpsl_pm.dev, "User triggered wakeup in offline charger.\n");

- if ((!sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_LOCK)) || (sharpsl_fatal_check() < 0) )

- dev_err(sharpsl_pm.dev, "Fatal condition. Suspend.\n");

- dev_dbg(sharpsl_pm.dev, "SharpSL suspending for first time.\n");

- while (corgi_enter_suspend(alarm_time,alarm_status,state))

- dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check entered\n");

- acin = sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_ACIN);

- sharpsl_pm.machinfo->discharge(1); /* enable discharge */

- buff[i] = sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT);

- dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check: acin: %d, discharge voltage: %d, no discharge: %ld\n", acin, temp, sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT));

- if ((acin && (temp < sharpsl_pm.machinfo->fatal_acin_volt)) ||

- (!acin && (temp < sharpsl_pm.machinfo->fatal_noacin_volt)))

- dev_err(sharpsl_pm.dev, "Offline Charger: Error occurred.\n");

- * Return 0 - sleep or wakeup depending on other factors

- dev_dbg(sharpsl_pm.dev, "Charge Mode: %d\n", sharpsl_pm.charge_mode);

- if ((sharpsl_ac_check() < 0) || (sharpsl_check_battery_temp() < 0))

- if ((sharpsl_check_battery_temp() < 0) || (sharpsl_check_battery_voltage() < 0))

- if (sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_CHRGFULL)) {

- dev_dbg(sharpsl_pm.dev, "Offline Charger: Charge full occurred. Retrying to check\n");

- if (sharpsl_pm.full_count > SHARPSL_CHARGE_RETRY_CNT) {

- dev_dbg(sharpsl_pm.dev, "Offline Charger: Not charged sufficiently. Retrying.\n");

- if (sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_CHRGFULL)) {

- dev_dbg(sharpsl_pm.dev, "Offline Charger: Charging complete.\n");

-static ssize_t battery_percentage_show(struct device *dev, struct device_attribute *attr, char *buf)

- return sprintf(buf, "%d\n",sharpsl_pm.battstat.mainbat_percent);

-static ssize_t battery_voltage_show(struct device *dev, struct device_attribute *attr, char *buf)

- return sprintf(buf, "%d\n",sharpsl_pm.battstat.mainbat_voltage);

-static DEVICE_ATTR(battery_percentage, 0444, battery_percentage_show, NULL);

-static DEVICE_ATTR(battery_voltage, 0444, battery_voltage_show, NULL);

-extern void (*apm_get_power_status)(struct apm_power_info *);

-static void sharpsl_apm_get_power_status(struct apm_power_info *info)

- info->battery_status = sharpsl_pm.battstat.mainbat_status;

- info->battery_life = sharpsl_pm.battstat.mainbat_percent;

-static int __init sharpsl_pm_probe(struct platform_device *pdev)

- sharpsl_pm.chrg_full_timer.function = sharpsl_chrg_full_timer;

- led_trigger_register_simple("sharpsl-charge", &sharpsl_charge_led_trigger);

- ret = device_create_file(&pdev->dev, &dev_attr_battery_percentage);

- ret |= device_create_file(&pdev->dev, &dev_attr_battery_voltage);

- dev_warn(&pdev->dev, "Failed to register attributes (%d)\n", ret);

- mod_timer(&sharpsl_pm.ac_timer, jiffies + msecs_to_jiffies(250));

-static int sharpsl_pm_remove(struct platform_device *pdev)

- device_remove_file(&pdev->dev, &dev_attr_battery_percentage);

- device_remove_file(&pdev->dev, &dev_attr_battery_voltage);

- led_trigger_unregister_simple(sharpsl_charge_led_trigger);

diff --git a/arch/arm/common/vic.c b/arch/arm/common/vic.c
index b2a781d9ce05..887c6eb3a18a 100644
--- a/arch/arm/common/vic.c
+++ b/arch/arm/common/vic.c

@@ -39,11 +40,219 @@ static void vic_unmask_irq(unsigned int irq)

+/* we cannot allocate memory when VICs are initially registered */

+static struct vic_device vic_devices[CONFIG_ARM_VIC_NR];

+static inline struct vic_device *to_vic(struct sys_device *sys)

+ printk(KERN_DEBUG "%s: resuming vic at %p\n", __func__, base);

+ /* set the enabled ints and then clear the non-enabled */

+static int vic_class_suspend(struct sys_device *dev, pm_message_t state)

+ printk(KERN_DEBUG "%s: suspending vic at %p\n", __func__, base);

+ writel(~vic->resume_irqs, base + VIC_INT_ENABLE_CLEAR);

+ * vic_pm_register - Register a VIC for later power management control

+ * @resume_sources: bitmask of interrupts allowed for resume sources.

+ * Register the VIC with the system device tree so that it can be notified

+ * of suspend and resume requests and ensure that the correct actions are

+static void __init vic_pm_register(void __iomem *base, unsigned int irq, u32 resume_sources)

+ printk(KERN_ERR "%s: too few VICs, increase CONFIG_ARM_VIC_NR\n", __func__);

+ printk(KERN_ERR "%s: cannot register class\n", __func__);

+static struct vic_device *vic_from_irq(unsigned int irq)

+static int vic_set_wake(unsigned int irq, unsigned int on)

+static inline void vic_pm_register(void __iomem *base, unsigned int irq, u32 arg1) { }

* @irq_start: starting interrupt number, must be muliple of 32

+ * @resume_sources: bitmask of interrupt sources to allow for resume

void __init vic_init(void __iomem *base, unsigned int irq_start,

@@ -77,12 +287,7 @@ void __init vic_init(void __iomem *base, unsigned int irq_start,

@@ -94,4 +299,6 @@ void __init vic_init(void __iomem *base, unsigned int irq_start,

diff --git a/arch/arm/configs/cm_x300_defconfig b/arch/arm/configs/cm_x300_defconfig
index 227da0843ead..d18d21bb41e4 100644
--- a/arch/arm/configs/cm_x300_defconfig
+++ b/arch/arm/configs/cm_x300_defconfig

@@ -287,7 +307,7 @@ CONFIG_CMDLINE="root=/dev/mtdblock5 rootfstype=jffs2 console=ttyS2,38400"

+# Enable WiMAX (Networking options) to see the WiMAX drivers

-# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'

-# may also be needed; see USB_STORAGE Help for more information

+# iptables trigger is under Netfilter config (LED target)

@@ -1173,15 +1294,13 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"

diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index eb2738b5be5f..ac18662f38cc 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig

diff --git a/arch/arm/configs/ep93xx_defconfig b/arch/arm/configs/ep93xx_defconfig
index 3f89d5f25bce..3fb083b81b0a 100644
--- a/arch/arm/configs/ep93xx_defconfig
+++ b/arch/arm/configs/ep93xx_defconfig

CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

CONFIG_CMDLINE="console=ttyAM0,115200 root=/dev/nfs ip=bootp"

-# Serial ATA (prod) and Parallel ATA (experimental) drivers

+# Enable WiMAX (Networking options) to see the WiMAX drivers

@@ -621,104 +673,101 @@ CONFIG_SERIAL_AMBA_PL010_CONSOLE=y

+# I2C system bus drivers (mostly embedded / system-on-chip)

-# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'

-# may also be needed; see USB_STORAGE Help for more information

@@ -1032,16 +1150,13 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"

diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index dcf8153a947d..0a1abb978d7e 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig

diff --git a/arch/arm/configs/magician_defconfig b/arch/arm/configs/magician_defconfig
index f56837f69ca7..957fd5fa27ca 100644
--- a/arch/arm/configs/magician_defconfig
+++ b/arch/arm/configs/magician_defconfig

diff --git a/arch/arm/configs/mx21_defconfig b/arch/arm/configs/mx21_defconfig
new file mode 100644
index 000000000000..4b04290d8e81
--- /dev/null
+++ b/arch/arm/configs/mx21_defconfig

+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

+# Enable WiMAX (Networking options) to see the WiMAX drivers

+# I2C system bus drivers (mostly embedded / system-on-chip)

diff --git a/arch/arm/configs/omap3_evm_defconfig b/arch/arm/configs/omap3_evm_defconfig
new file mode 100644
index 000000000000..28be17fbc157
--- /dev/null
+++ b/arch/arm/configs/omap3_evm_defconfig

+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

+CONFIG_CMDLINE="root=/dev/nfs nfsroot=192.168.0.1:/home/user/buildroot ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:tgt:eth0:off rw console=ttyS2,115200n8"

+# Some SCSI devices (e.g. CD jukebox) support multiple LUNs

+# Enable WiMAX (Networking options) to see the WiMAX drivers

+# I2C system bus drivers (mostly embedded / system-on-chip)

diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig
new file mode 100644
index 000000000000..23e43ea4efa1
--- /dev/null
+++ b/arch/arm/configs/omap_4430sdp_defconfig

+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

+CONFIG_CMDLINE="root=/dev/ram0 rw mem=128M console=ttyS0,115200n8 initrd=0x81600000,20M ramdisk_size=20480"

diff --git a/arch/arm/configs/omap_zoom2_defconfig b/arch/arm/configs/omap_zoom2_defconfig
new file mode 100644
index 000000000000..213fe9c5eaae
--- /dev/null
+++ b/arch/arm/configs/omap_zoom2_defconfig

+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

+CONFIG_CMDLINE="root=/dev/nfs nfsroot=192.168.0.1:/home/user/buildroot ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:tgt:eth0:off rw console=ttyS2,115200n8"

+# Some SCSI devices (e.g. CD jukebox) support multiple LUNs

+# I2C system bus drivers (mostly embedded / system-on-chip)

diff --git a/arch/arm/configs/orion5x_defconfig b/arch/arm/configs/orion5x_defconfig
index 5b98f7645119..9e2385293ecb 100644
--- a/arch/arm/configs/orion5x_defconfig
+++ b/arch/arm/configs/orion5x_defconfig

diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig
index 593102da8cd7..eb2cb31825c0 100644
--- a/arch/arm/configs/rx51_defconfig
+++ b/arch/arm/configs/rx51_defconfig

-CONFIG_CMDLINE="init=/sbin/preinit ubi.mtd=4 root=ubi0:rootfs rootfstype=ubifs rw console=ttyMTD5"

+CONFIG_CMDLINE="init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw console=ttyMTD,log console=tty0"

diff --git a/arch/arm/configs/stmp378x_defconfig b/arch/arm/configs/stmp378x_defconfig
new file mode 100644
index 000000000000..44461f197a17
--- /dev/null
+++ b/arch/arm/configs/stmp378x_defconfig

+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

+# Some SCSI devices (e.g. CD jukebox) support multiple LUNs

diff --git a/arch/arm/configs/stmp37xx_defconfig b/arch/arm/configs/stmp37xx_defconfig
new file mode 100644
index 000000000000..401279d531d5
--- /dev/null
+++ b/arch/arm/configs/stmp37xx_defconfig

+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

+CONFIG_CMDLINE="console=ttySDBG0,115200 mem=32M lcd_panel=lms350 rdinit=/bin/sh ignore_loglevel"

+# Some SCSI devices (e.g. CD jukebox) support multiple LUNs

diff --git a/arch/arm/configs/u300_defconfig b/arch/arm/configs/u300_defconfig
new file mode 100644
index 000000000000..2d827e121147
--- /dev/null
+++ b/arch/arm/configs/u300_defconfig

+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

+# All the settings below must match the bootloader's settings

+CONFIG_CMDLINE="root=/dev/mtdblock2 rw rootfstype=yaffs2 console=ttyAMA0,115200n8 ab3100.force=0,0x48 mtdparts=u300nand:128k@0x0(bootrecords)ro,8064k@128k(free)ro,253952k@8192k(platform) lpj=515072"

+# I2C system bus drivers (mostly embedded / system-on-chip)

+# iptables trigger is under Netfilter config (LED target)

diff --git a/arch/arm/configs/w90p910_defconfig b/arch/arm/configs/w90p910_defconfig
index 56bda7c6d670..5245655a0ad3 100644
--- a/arch/arm/configs/w90p910_defconfig
+++ b/arch/arm/configs/w90p910_defconfig

CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

-CONFIG_CMDLINE="root=/dev/ram0 console=ttyS0,115200n8 initrd=0xa00000,4000000 mem=64M"

+CONFIG_CMDLINE="root=/dev/ram0 console=ttyS0,115200n8 rdinit=/sbin/init mem=64M"

+# Some SCSI devices (e.g. CD jukebox) support multiple LUNs

diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 6116e4893c0a..15f8a092b700 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h

diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index ee99723b3a6c..9e07fe507029 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h

@@ -44,11 +44,29 @@ static inline void atomic_set(atomic_t *v, int i)

@@ -59,14 +77,34 @@ static inline int atomic_add_return(int i, atomic_t *v)

@@ -77,6 +115,8 @@ static inline int atomic_sub_return(int i, atomic_t *v)

@@ -84,6 +124,8 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)

@@ -95,6 +137,8 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)

@@ -135,6 +179,7 @@ static inline int atomic_add_return(int i, atomic_t *v)

@@ -148,6 +193,7 @@ static inline int atomic_sub_return(int i, atomic_t *v)

static inline int atomic_cmpxchg(atomic_t *v, int old, int new)

@@ -187,10 +233,8 @@ static inline int atomic_add_unless(atomic_t *v, int a, int u)

#define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)

#define atomic_inc_and_test(v) (atomic_add_return(1, v) == 0)

#define atomic_dec_and_test(v) (atomic_sub_return(1, v) == 0)

@@ -200,12 +244,11 @@ static inline int atomic_add_unless(atomic_t *v, int a, int u)

#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)

diff --git a/arch/arm/include/asm/bitsperlong.h b/arch/arm/include/asm/bitsperlong.h
new file mode 100644
index 000000000000..6dc0bb0c13b2
--- /dev/null
+++ b/arch/arm/include/asm/bitsperlong.h

diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
index cb7a9e97fd7e..feaa75f0013e 100644
--- a/arch/arm/include/asm/cache.h
+++ b/arch/arm/include/asm/cache.h

+ * Memory returned by kmalloc() may be used for DMA, so we must make

+ * sure that all such allocations are cache aligned. Otherwise,

+ * unrelated code may cause parts of the buffer to be read into the

+ * cache before the transfer is done, causing old data to be seen by

+ * With EABI on ARMv5 and above we must have 64-bit aligned slab pointers.

diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index bb7d695f3900..1a711ea8418b 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h

@@ -429,6 +429,14 @@ static inline void flush_anon_page(struct vm_area_struct *vma,

+static inline void flush_kernel_dcache_page(struct page *page)

+ /* highmem pages are always flushed upon kunmap already */

+ if ((cache_is_vivt() || cache_is_vipt_aliasing()) && !PageHighMem(page))

diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 7b9d27e749b8..b3e656c6fb78 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h

diff --git a/arch/arm/include/asm/flat.h b/arch/arm/include/asm/flat.h
index 1d77e51907f6..59426a4595c9 100644
--- a/arch/arm/include/asm/flat.h
+++ b/arch/arm/include/asm/flat.h

-/* An odd number of words will be pushed after this alignment, so

-#define flat_stack_align(sp) sp = (void *)(((unsigned long)(sp) - 4) | 4)

#define flat_reloc_valid(reloc, size) ((reloc) <= (size))

diff --git a/arch/arm/include/asm/hardware/arm_twd.h b/arch/arm/include/asm/hardware/arm_twd.h
deleted file mode 100644
index e521b70713c8..000000000000
--- a/arch/arm/include/asm/hardware/arm_twd.h
+++ /dev/null

diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
index 64f2252a25cd..cdb9022716fd 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h

diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
index 4924914af188..7f34333bb545 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h

void gic_dist_init(unsigned int gic_nr, void __iomem *base, unsigned int irq_start);

void gic_cpu_init(unsigned int gic_nr, void __iomem *base);

void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);

-void gic_raise_softirq(cpumask_t cpumask, unsigned int irq);

+void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);

diff --git a/arch/arm/include/asm/hardware/pl080.h b/arch/arm/include/asm/hardware/pl080.h
new file mode 100644
index 000000000000..6a6c66be7f65
--- /dev/null
+++ b/arch/arm/include/asm/hardware/pl080.h

+ * This program is free software; you can redistribute it and/or modify

+ * it under the terms of the GNU General Public License version 2 as

+/* Note, there are some Samsung updates to this controller block which

+ * make it not entierly compatible with the PL080 specification from

+ * ARM. When in doubt, check the Samsung documentation first.

+ * The Samsung defines are PL080S, and add an extra controll register,

+ * the ability to move more than 2^11 counts of data and some extra

diff --git a/arch/arm/include/asm/hardware/vic.h b/arch/arm/include/asm/hardware/vic.h
index f87328d4a180..5d72550a8097 100644
--- a/arch/arm/include/asm/hardware/vic.h
+++ b/arch/arm/include/asm/hardware/vic.h

-void vic_init(void __iomem *base, unsigned int irq_start, u32 vic_sources);

+void vic_init(void __iomem *base, unsigned int irq_start, u32 vic_sources, u32 resume_sources);

diff --git a/arch/arm/include/asm/localtimer.h b/arch/arm/include/asm/localtimer.h
new file mode 100644
index 000000000000..50c7e7cfd670
--- /dev/null
+++ b/arch/arm/include/asm/localtimer.h

+ * This program is free software; you can redistribute it and/or modify

+ * it under the terms of the GNU General Public License version 2 as

+ * Setup a per-cpu timer, whether it be a local timer or dummy broadcast

+ * Called from assembly, this is the local timer IRQ handler

+ * Platform provides this to acknowledge a local timer IRQ.

+ * Returns true if the local timer IRQ is to be processed.

diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 58cf91f38e6f..742c2aaeb020 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h

+extern const struct mem_type *get_mem_type(unsigned int type);

+ * external interface to remap single page with appropriate type

+extern int ioremap_page(unsigned long virt, unsigned long phys,

diff --git a/arch/arm/include/asm/mman.h b/arch/arm/include/asm/mman.h
index 54570d2e95b7..fc26976d8e3a 100644
--- a/arch/arm/include/asm/mman.h
+++ b/arch/arm/include/asm/mman.h

diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index e6eb8a67b807..be962c1349c4 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h

(((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0) | \

VM_READ | VM_WRITE | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)

- * With EABI on ARMv5 and above we must have 64-bit aligned slab pointers.

diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 110295c5461d..1cd2d6416bda 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h

@@ -342,7 +342,7 @@ static inline pte_t *pmd_page_vaddr(pmd_t pmd)

+#define pmd_page(pmd) pfn_to_page(__phys_to_pfn(pmd_val(pmd)))

* Conversion functions: convert a page and protection to a page entry,

diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 1845892260e7..6a89567ffc5b 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h

diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
index 236a06b9b7ce..67b833c9b6b9 100644
--- a/arch/arm/include/asm/ptrace.h
+++ b/arch/arm/include/asm/ptrace.h

+#define PSR_ISET_MASK 0x01000010 /* ISA state (J, T) mask */

+#define PSR_IT_MASK 0x0600fc00 /* If-Then execution state mask */

+#define PSR_ENDIAN_MASK 0x00000200 /* Endianness state mask */

diff --git a/arch/arm/include/asm/signal.h b/arch/arm/include/asm/signal.h
index d0fb487aba4f..43ba0fb1c8ad 100644
--- a/arch/arm/include/asm/signal.h
+++ b/arch/arm/include/asm/signal.h

diff --git a/arch/arm/include/asm/sizes.h b/arch/arm/include/asm/sizes.h
index ada93a8fc2ef..4fc1565e4f93 100644
--- a/arch/arm/include/asm/sizes.h
+++ b/arch/arm/include/asm/sizes.h

diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index fad70da5911d..a06e735b262a 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h

@@ -41,7 +41,7 @@ extern void show_ipi_list(struct seq_file *p);

+ * Setup the set of possible CPUs (via set_cpu_possible)

@@ -53,17 +53,7 @@ extern void smp_store_cpu_info(unsigned int cpuid);

* Boot a secondary CPU, and assign it the specified idle task.

@@ -102,46 +92,12 @@ extern int platform_cpu_kill(unsigned int cpu);

-extern void arch_send_call_function_ipi(cpumask_t mask);

- * Local timer interrupt handling function (can be IPI'ed).

- * Platform provides this to acknowledge a local timer IRQ

+extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);

+#define arch_send_call_function_ipi_mask arch_send_call_function_ipi_mask

- * Called from assembly, this is the local timer IRQ handler

diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
new file mode 100644
index 000000000000..2376835015d6
--- /dev/null
+++ b/arch/arm/include/asm/smp_scu.h

diff --git a/arch/arm/include/asm/smp_twd.h b/arch/arm/include/asm/smp_twd.h
new file mode 100644
index 000000000000..7be0978b2625
--- /dev/null
+++ b/arch/arm/include/asm/smp_twd.h

diff --git a/arch/arm/include/asm/suspend.h b/arch/arm/include/asm/suspend.h
deleted file mode 100644
index cf0d0bdee74d..000000000000
--- a/arch/arm/include/asm/suspend.h
+++ /dev/null

diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index bd4dc8ed53d5..d65b2f5bf41f 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h

@@ -248,6 +248,8 @@ static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size

@@ -307,6 +309,7 @@ static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size

* cmpxchg_local and cmpxchg64_local are atomic wrt current CPU. Always make

+extern void __bad_cmpxchg(volatile void *ptr, int size);

+static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,

+static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,

+static inline unsigned long __cmpxchg_local(volatile void *ptr,

+ * Note : ARMv7-M (currently unsupported by Linux) does not support

+ * ldrexd/strexd. If ARMv7-M is ever supported by the Linux kernel, it should

+static inline unsigned long long __cmpxchg64(volatile void *ptr,

+static inline unsigned long long __cmpxchg64_mb(volatile void *ptr,

+#define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))

diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index a62218013c78..c964f3fc3bc5 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h

+/* Unified Inner Shareable TLB operations (ARMv7 MP extensions) */

+#define v7wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_BTB | \

@@ -316,6 +330,8 @@ static inline void local_flush_tlb_all(void)

+ asm("mcr p15, 0, %0, c8, c3, 0" : : "r" (zero) : "cc");

@@ -351,6 +367,8 @@ static inline void local_flush_tlb_mm(struct mm_struct *mm)

+ asm("mcr p15, 0, %0, c8, c3, 2" : : "r" (asid) : "cc");

@@ -389,6 +407,8 @@ local_flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)

+ asm("mcr p15, 0, %0, c8, c3, 1" : : "r" (uaddr) : "cc");

@@ -424,6 +444,8 @@ static inline void local_flush_tlb_kernel_page(unsigned long kaddr)

+ asm("mcr p15, 0, %0, c8, c3, 1" : : "r" (kaddr) : "cc");

diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 7897464e0c24..0da9bc9b3b1d 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h

extern unsigned long __must_check __copy_from_user(void *to, const void __user *from, unsigned long n);

extern unsigned long __must_check __copy_to_user(void __user *to, const void *from, unsigned long n);

+extern unsigned long __must_check __copy_to_user_std(void __user *to, const void *from, unsigned long n);

extern unsigned long __must_check __clear_user(void __user *addr, unsigned long n);

+extern unsigned long __must_check __clear_user_std(void __user *addr, unsigned long n);

#define __copy_from_user(to,from,n) (memcpy(to, (void __force *)from, n), 0)

#define __copy_to_user(to,from,n) (memcpy((void __force *)to, from, n), 0)

diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 11a5197a221f..ff89d0b3abc5 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile

diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c
index d4a0da1e48f4..950391f194c4 100644
--- a/arch/arm/kernel/elf.c
+++ b/arch/arm/kernel/elf.c

@@ -78,6 +78,15 @@ int arm_elf_read_implies_exec(const struct elf32_hdr *x, int executable_stack)

+#if !defined(CONFIG_AEABI) || defined(CONFIG_OABI_COMPAT)

+ * If we have support for OABI programs, we can never allow NX

+ * support - our signal syscall restart mechanism relies upon

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index d662a2f1fd85..fc8af43c5000 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S

diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index b55cb0331809..366e5097a41a 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S

diff --git a/arch/arm/kernel/init_task.c b/arch/arm/kernel/init_task.c
index e859af349467..3f470866bb89 100644
--- a/arch/arm/kernel/init_task.c
+++ b/arch/arm/kernel/init_task.c

static struct signal_struct init_signals = INIT_SIGNALS(init_signals);

static struct sighand_struct init_sighand = INIT_SIGHAND(init_sighand);

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index c3265a2e7cd4..1585423699ee 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c

@@ -365,7 +365,7 @@ pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)

return do_fork(flags|CLONE_VM|CLONE_UNTRACED, 0, &regs, 0, NULL, NULL);

diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
index 80b8b5c7e07a..93bb4247b7ed 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c

@@ -426,9 +426,13 @@ setup_return(struct pt_regs *regs, struct k_sigaction *ka,

@@ -532,7 +536,7 @@ setup_rt_frame(int usig, struct k_sigaction *ka, siginfo_t *info,

-static inline void restart_syscall(struct pt_regs *regs)

+static inline void setup_syscall_restart(struct pt_regs *regs)

@@ -567,7 +571,7 @@ handle_signal(unsigned long sig, struct k_sigaction *ka,

@@ -691,7 +695,7 @@ static int do_signal(sigset_t *oldset, struct pt_regs *regs, int syscall)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7801aac3c043..de885fd256c5 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c

* as from 2.5, kernels no longer have an init_tasks structure

* Take this CPU offline. Once we clear this, we can't return,

* and we must not schedule until we're ready to give up the cpu.

@@ -274,9 +278,9 @@ asmlinkage void __cpuinit secondary_start_kernel(void)

@@ -285,7 +289,7 @@ asmlinkage void __cpuinit secondary_start_kernel(void)

@@ -326,14 +330,14 @@ void __init smp_prepare_boot_cpu(void)

-static void send_ipi_message(cpumask_t callmap, enum ipi_msg_type msg)

+static void send_ipi_message(const struct cpumask *mask, enum ipi_msg_type msg)

@@ -344,19 +348,19 @@ static void send_ipi_message(cpumask_t callmap, enum ipi_msg_type msg)

+void arch_send_call_function_ipi_mask(const struct cpumask *mask)

- send_ipi_message(cpumask_of_cpu(cpu), IPI_CALL_FUNC_SINGLE);

+ send_ipi_message(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);

@@ -383,10 +387,16 @@ void show_local_irqs(struct seq_file *p)

+static DEFINE_PER_CPU(struct clock_event_device, percpu_clockevent);

+ struct clock_event_device *evt = &__get_cpu_var(percpu_clockevent);

@@ -405,6 +415,42 @@ asmlinkage void __exception do_local_timer(struct pt_regs *regs)

+static void smp_timer_broadcast(const struct cpumask *mask)

+static void broadcast_timer_set_mode(enum clock_event_mode mode,

+static void local_timer_setup(struct clock_event_device *evt)

+ struct clock_event_device *evt = &per_cpu(percpu_clockevent, cpu);

@@ -417,7 +463,7 @@ static void ipi_cpu_stop(unsigned int cpu)

@@ -498,26 +544,14 @@ asmlinkage void __exception do_IPI(struct pt_regs *regs)

@@ -528,20 +562,17 @@ int setup_profiling_timer(unsigned int multiplier)

-on_each_cpu_mask(void (*func)(void *), void *info, int wait, cpumask_t mask)

+on_each_cpu_mask(void (*func)(void *), void *info, int wait,

/**********************************************************************/

+/* all SMP configurations have the extended CPUID registers */

+ return ((read_cpuid_ext(CPUID_EXT_MMFR3) >> 12) & 0xf) < 2;

@@ -597,55 +634,61 @@ static inline void ipi_flush_tlb_kernel_range(void *arg)

+ on_each_cpu_mask(ipi_flush_tlb_mm, mm, 1, &mm->cpu_vm_mask);

void flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)

+ on_each_cpu_mask(ipi_flush_tlb_page, &ta, 1, &vma->vm_mm->cpu_vm_mask);

+ on_each_cpu_mask(ipi_flush_tlb_range, &ta, 1, &vma->vm_mm->cpu_vm_mask);

void flush_tlb_kernel_range(unsigned long start, unsigned long end)

diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
new file mode 100644
index 000000000000..d3831f616ee9
--- /dev/null
+++ b/arch/arm/kernel/smp_scu.c

+ * This program is free software; you can redistribute it and/or modify

+ * it under the terms of the GNU General Public License version 2 as

+ * Get the number of CPU cores from the SCU configuration

+unsigned int __init scu_get_core_count(void __iomem *scu_base)

+ unsigned int ncores = __raw_readl(scu_base + SCU_CONFIG);

+ * Ensure that the data accessed by CPU0 before the SCU was

diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
new file mode 100644
index 000000000000..d8c88c633c6f
--- /dev/null
+++ b/arch/arm/kernel/smp_twd.c

+ * This program is free software; you can redistribute it and/or modify

+ * it under the terms of the GNU General Public License version 2 as

+ ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE

+ /* period set, and timer enabled in 'next_event' hook */

+ ctrl = TWD_TIMER_CONTROL_IT_ENABLE | TWD_TIMER_CONTROL_ONESHOT;

+ unsigned long ctrl = __raw_readl(twd_base + TWD_TIMER_CONTROL);

+ * If a local timer interrupt has occurred, acknowledge and return 1.

+ * If this is the first time round, we need to work out how fast

+ /* OK, now the tick has started, let's get the timer going */

+ __raw_writel(0xFFFFFFFFU, twd_base + TWD_TIMER_COUNTER);

+void __cpuinit twd_timer_setup(struct clock_event_device *clk)

+ clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;

+ clk->mult = div_sc(twd_timer_rate, NSEC_PER_SEC, clk->shift);

+ clk->max_delta_ns = clockevent_delta2ns(0xffffffff, clk);

+ /* Make sure our local interrupt controller has this enabled */

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index c90f27250ead..6c0779792546 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 866f84a586ff..030ba7219f48 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile

+# using lib_ here won't override already available weak symbols

+obj-$(CONFIG_UACCESS_WITH_MEMCPY) += uaccess_with_memcpy.o

diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index 2e787d40d599..c7f2627385e7 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h

diff --git a/arch/arm/lib/clear_user.S b/arch/arm/lib/clear_user.S
index 4d6bc71231f3..844f56785ebc 100644
--- a/arch/arm/lib/clear_user.S
+++ b/arch/arm/lib/clear_user.S

diff --git a/arch/arm/lib/copy_to_user.S b/arch/arm/lib/copy_to_user.S
index 22f968bbdffd..878820f0a320 100644
--- a/arch/arm/lib/copy_to_user.S
+++ b/arch/arm/lib/copy_to_user.S

diff --git a/arch/arm/lib/uaccess_with_memcpy.c b/arch/arm/lib/uaccess_with_memcpy.c
new file mode 100644
index 000000000000..6b967ffb6552
--- /dev/null
+++ b/arch/arm/lib/uaccess_with_memcpy.c

+ * This program is free software; you can redistribute it and/or modify

+ * it under the terms of the GNU General Public License version 2 as

+pin_page_for_write(const void __user *_addr, pte_t **ptep, spinlock_t **ptlp)

+ pte = pte_offset_map_lock(current->mm, pmd, addr, &ptl);

+__copy_to_user_memcpy(void __user *to, const void *from, unsigned long n)

+ /* the mmap semaphore is taken only if not in an atomic context */

+__copy_to_user(void __user *to, const void *from, unsigned long n)

+ * This test is stubbed out of the main function above to keep

+ * the overhead for small copies low by avoiding a large

+ * register dump on the stack just to reload them right away.

+ * With frame pointer disabled, tail call optimization kicks in

+unsigned long __clear_user(void __user *addr, unsigned long n)

+ * This code is disabled by default, but kept around in case the chosen

+ * thresholds need to be revalidated. Some overhead (small but still)

+ * would be implied by a runtime determined variable threshold, and

+ * so far the measurement on concerned targets didn't show a worthwhile

+ * Note that a fairly precise sched_clock() implementation is needed

+ user_ptr = vmap(&dst_page, 1, VM_IOREMAP, __pgprot(__P010));

+ ret = __copy_to_user_memcpy(user_ptr, kernel_ptr, PAGE_SIZE);

+ ret |= __copy_to_user_memcpy(user_ptr, kernel_ptr, size);

+ printk("copy_to_user: %d %llu %llu\n", size, t1 - t0, t2 - t1);

+ printk("clear_user: %d %llu %llu\n", size, t1 - t0, t2 - t1);

diff --git a/arch/arm/mach-at91/board-afeb-9260v1.c b/arch/arm/mach-at91/board-afeb-9260v1.c
index e263fda3e2d1..970fd6b6753e 100644
--- a/arch/arm/mach-at91/board-afeb-9260v1.c
+++ b/arch/arm/mach-at91/board-afeb-9260v1.c

@@ -156,6 +156,8 @@ static struct atmel_nand_data __initdata afeb9260_nand_data = {

static struct at91_mmc_data __initdata afeb9260_mmc_data = {

@@ -164,6 +166,8 @@ static struct at91_mmc_data __initdata afeb9260_mmc_data = {

static struct i2c_board_info __initdata afeb9260_i2c_devices[] = {

@@ -196,6 +200,8 @@ static void __init afeb9260_board_init(void)

diff --git a/arch/arm/mach-at91/board-sam9g20ek.c b/arch/arm/mach-at91/board-sam9g20ek.c
index 438efbb17482..cc270beadd5d 100644
--- a/arch/arm/mach-at91/board-sam9g20ek.c
+++ b/arch/arm/mach-at91/board-sam9g20ek.c

@@ -218,6 +218,13 @@ static struct gpio_led ek_leds[] = {

+static struct i2c_board_info __initdata ek_i2c_devices[] = {

@@ -235,7 +242,7 @@ static void __init ek_board_init(void)

+ at91_add_device_i2c(ek_i2c_devices, ARRAY_SIZE(ek_i2c_devices));

diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
index e4345106ee57..bac578fe0d3d 100644
--- a/arch/arm/mach-at91/clock.c
+++ b/arch/arm/mach-at91/clock.c

+ * Chips have some kind of clocks : group them by functionality

@@ -173,7 +192,11 @@ static struct clk __init *at91_css_to_clk(unsigned long css)

@@ -322,7 +345,7 @@ int clk_set_rate(struct clk *clk, unsigned long rate)

@@ -361,7 +384,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent)

static void __init init_programmable_clock(struct clk *clk)

@@ -389,11 +412,13 @@ static int at91_clk_show(struct seq_file *s, void *unused)

seq_printf(s, "MOR = %8x\n", at91_sys_read(AT91_CKGR_MOR));

seq_printf(s, "MCFR = %8x\n", at91_sys_read(AT91_CKGR_MCFR));

seq_printf(s, "PLLA = %8x\n", at91_sys_read(AT91_CKGR_PLLAR));

seq_printf(s, "PLLB = %8x\n", at91_sys_read(AT91_CKGR_PLLBR));

seq_printf(s, "UCKR = %8x\n", uckr = at91_sys_read(AT91_CKGR_UCKR));

seq_printf(s, "MCKR = %8x\n", at91_sys_read(AT91_PMC_MCKR));

+ seq_printf(s, "USB = %8x\n", at91_sys_read(AT91_PMC_USB));

seq_printf(s, "SR = %8x\n", sr = at91_sys_read(AT91_PMC_SR));

@@ -554,16 +579,60 @@ static struct clk *const standard_pmc_clocks[] __initdata = {

+static void __init at91_pllb_usbfs_clock_init(unsigned long main_clock)

+ at91_pllb_usb_init = at91_pll_calc(main_clock, 48000000 * 2) | AT91_PMC_USB96M;

+ pllb.rate_hz = at91_pll_rate(&pllb, main_clock, at91_pllb_usb_init);

+ } else if (cpu_is_at91sam9260() || cpu_is_at91sam9261() || cpu_is_at91sam9263() || cpu_is_at91sam9g20()) {

+ udpck.rate_hz = at91_usb_rate(&pllb, pllb.rate_hz, at91_pllb_usb_init);

+ uhpck.rate_hz = at91_usb_rate(&pllb, pllb.rate_hz, at91_pllb_usb_init);

+static void __init at91_upll_usbfs_clock_init(unsigned long main_clock)

+ uhpck.rate_hz /= 1 + ((at91_sys_read(AT91_PMC_USB) & AT91_PMC_OHCIUSBDIV) >> 8);

@@ -585,43 +654,37 @@ int __init at91_clock_init(unsigned long main_clock)

plla.rate_hz = at91_pll_rate(&plla, main_clock, at91_sys_read(AT91_CKGR_PLLAR));

- if ((!cpu_is_at91sam9g20() && plla.rate_hz > 209000000)

pr_info("Clocks: PLLA overclocked, %ld MHz\n", plla.rate_hz / 1000000);

- at91_pllb_usb_init = at91_pll_calc(main_clock, 48000000 * 2) | AT91_PMC_USB96M;

- pllb.rate_hz = at91_pll_rate(&pllb, main_clock, at91_pllb_usb_init);

- } else if (cpu_is_at91sam9260() || cpu_is_at91sam9261() || cpu_is_at91sam9263() || cpu_is_at91sam9g20()) {

- udpck.rate_hz = at91_usb_rate(&pllb, pllb.rate_hz, at91_pllb_usb_init);

- uhpck.rate_hz = at91_usb_rate(&pllb, pllb.rate_hz, at91_pllb_usb_init);

* (obtain the USB High Speed 480 MHz when input is 12 MHz)

@@ -631,21 +694,31 @@ int __init at91_clock_init(unsigned long main_clock)

freq /= (1 << ((mckr & AT91_PMC_PRES) >> 2)); /* prescale */

mck.rate_hz = freq / (1 + ((mckr & AT91_PMC_MDIV) >> 8)); /* mdiv */

freq / ((mckr & AT91_PMC_MDIV) >> 7) : freq; /* mdiv ; (x >> 7) = ((x >> 8) * 2) */

mck.rate_hz = freq / (1 << ((mckr & AT91_PMC_MDIV) >> 8)); /* mdiv */

diff --git a/arch/arm/mach-at91/include/mach/at91_pmc.h b/arch/arm/mach-at91/include/mach/at91_pmc.h
index 9561e33b8a9a..64589eaaaee8 100644
--- a/arch/arm/mach-at91/include/mach/at91_pmc.h
+++ b/arch/arm/mach-at91/include/mach/at91_pmc.h

#define AT91RM9200_PMC_UDP (1 << 1) /* USB Devcice Port Clock [AT91RM9200 only] */

#define AT91RM9200_PMC_MCKUDP (1 << 2) /* USB Device Port Master Clock Automatic Disable on Suspend [AT91RM9200 only] */

-#define AT91CAP9_PMC_DDR (1 << 2) /* DDR Clock [AT91CAP9 revC only] */

+#define AT91CAP9_PMC_DDR (1 << 2) /* DDR Clock [CAP9 revC & some SAM9 only] */

#define AT91RM9200_PMC_UHP (1 << 4) /* USB Host Port Clock [AT91RM9200 only] */

#define AT91SAM926x_PMC_UHP (1 << 6) /* USB Host Port Clock [AT91SAM926x only] */

#define AT91CAP9_PMC_UHP (1 << 6) /* USB Host Port Clock [AT91CAP9 only] */

#define AT91_PMC_PCDR (AT91_PMC + 0x14) /* Peripheral Clock Disable Register */

#define AT91_PMC_PCSR (AT91_PMC + 0x18) /* Peripheral Clock Status Register */

-#define AT91_CKGR_UCKR (AT91_PMC + 0x1C) /* UTMI Clock Register [SAM9RL, CAP9] */

+#define AT91_CKGR_UCKR (AT91_PMC + 0x1C) /* UTMI Clock Register [some SAM9, CAP9] */

#define AT91_PMC_UPLLCOUNT (0xf << 20) /* UTMI PLL Start-up Time */

-#define AT91_PMC_BIASCOUNT (0xf << 28) /* UTMI PLL Start-up Time */

+#define AT91_PMC_BIASCOUNT (0xf << 28) /* UTMI BIAS Start-up Time */

#define AT91_CKGR_MOR (AT91_PMC + 0x20) /* Main Oscillator Register [not on SAM9RL] */

#define AT91_PMC_MOSCEN (1 << 0) /* Main Oscillator Enable */

+#define AT91_PMC_CSS_UPLL (3 << 0) /* [some SAM9 only] */

#define AT91_PMC_PRES (7 << 2) /* Master Clock Prescaler */

#define AT91SAM9_PMC_MDIV_1 (0 << 8) /* [SAM9,CAP9 only] */

+#define AT91SAM9_PMC_MDIV_6 (3 << 8) /* [some SAM9 only] */

+#define AT91SAM9_PMC_MDIV_3 (3 << 8) /* [some SAM9 only] */

#define AT91_PMC_PDIV (1 << 12) /* Processor Clock Division [some SAM9 only] */

+#define AT91_PMC_PLLADIV2 (1 << 12) /* PLLA divisor by 2 [some SAM9 only] */

-#define AT91_PMC_PCKR(n) (AT91_PMC + 0x40 + ((n) * 4)) /* Programmable Clock 0-3 Registers */

+#define AT91_PMC_USB (AT91_PMC + 0x38) /* USB Clock Register [some SAM9 only] */

+#define AT91_PMC_USBS (0x1 << 0) /* USB OHCI Input clock selection */

+#define AT91_PMC_OHCIUSBDIV (0xF << 8) /* Divider for USB OHCI Clock */

+#define AT91_PMC_PCKR(n) (AT91_PMC + 0x40 + ((n) * 4)) /* Programmable Clock 0-N Registers */

+#define AT91_PMC_CSSMCK (0x1 << 8) /* CSS or Master Clock Selection */

#define AT91_PMC_IER (AT91_PMC + 0x60) /* Interrupt Enable Register */

#define AT91_PMC_IDR (AT91_PMC + 0x64) /* Interrupt Disable Register */

-#define AT91_PMC_LOCKU (1 << 6) /* UPLL Lock [AT91CAP9 only] */

+#define AT91_PMC_LOCKU (1 << 6) /* UPLL Lock [some SAM9, AT91CAP9 only] */

#define AT91_PMC_OSCSEL (1 << 7) /* Slow Clock Oscillator [AT91CAP9 revC only] */

#define AT91_PMC_PCK0RDY (1 << 8) /* Programmable Clock 0 */

#define AT91_PMC_PCK1RDY (1 << 9) /* Programmable Clock 1 */

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index a9c78bc72b84..be747f5c6cd8 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig

Configure this option to specify the whether the board used

+ Configure this option to specify the whether the board used

diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 1674661942f3..059ab78084ba 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile

-obj-y := time.o irq.o clock.o serial.o io.o id.o psc.o \

+obj-$(CONFIG_MACH_DAVINCI_DM355_EVM) += board-dm355-evm.o

+obj-$(CONFIG_MACH_DM355_LEOPARD) += board-dm355-leopard.o

+obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM) += board-dm646x-evm.o

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
new file mode 100644
index 000000000000..5ac2f565d860
--- /dev/null
+++ b/arch/arm/mach-davinci/board-dm355-evm.c

+ * 2007 (c) MontaVista Software, Inc. This file is licensed under

+ * the terms of the GNU General Public License version 2. This program

+ * is licensed "as is" without any warranty of any kind, whether express

+/* NOTE: this is geared for the standard config, with a socketed

+ * 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you

+ * swap chips, maybe with a different block size, partitioning may

+static struct mtd_partition davinci_nand_partitions[] = {

+ /* two blocks with bad block table (and mirror) at the end */

+static struct platform_device *davinci_evm_devices[] __initdata = {

+static struct davinci_uart_config uart_config __initdata = {

+ return !gpio_get_value_cansleep(dm355evm_mmc_gpios + 2 * module + 1);

+ return gpio_get_value_cansleep(dm355evm_mmc_gpios + 2 * module + 0);

+static struct davinci_mmc_config dm355evm_mmc_config = {

+/* Don't connect anything to J10 unless you're only using USB host

+ * mode *and* have to do so with some kind of gender-bender. If

+ * you have proper Mini-B or Mini-A cables (or Mini-A adapters)

+#define USB_ID_VALUE 0 /* ID pulled high; *should* float */

+static struct spi_board_info dm355_evm_spi_info[] __initconst = {

+ /* NOTE: NAND flash timings set by the UBL are slower than

+ * needed by MT29F16G08FAA chips ... EMIF.A1CR is 0x40400204

+ * but could be 0x0400008c for about 25% faster page reads.

diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c
new file mode 100644
index 000000000000..28c9008df4f4
--- /dev/null
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c

+ * This file is licensed under the terms of the GNU General Public

+ * License version 2. This program is licensed "as is" without any

+/* NOTE: this is geared for the standard config, with a socketed

+ * 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you

+ * swap chips, maybe with a different block size, partitioning may

+static struct mtd_partition davinci_nand_partitions[] = {

+ /* two blocks with bad block table (and mirror) at the end */

+static struct i2c_board_info dm355leopard_i2c_info[] = {

+static struct platform_device *davinci_leopard_devices[] __initdata = {

+static struct davinci_uart_config uart_config __initdata = {

+ return !gpio_get_value_cansleep(leopard_mmc_gpio + 2 * module + 1);

+ return gpio_get_value_cansleep(leopard_mmc_gpio + 2 * module + 0);

+static struct davinci_mmc_config dm355leopard_mmc_config = {

+/* Don't connect anything to J10 unless you're only using USB host

+ * mode *and* have to do so with some kind of gender-bender. If

+ * you have proper Mini-B or Mini-A cables (or Mini-A adapters)

+#define USB_ID_VALUE 0 /* ID pulled high; *should* float */

+static struct spi_board_info dm355_leopard_spi_info[] __initconst = {

+ /* NOTE: NAND flash timings set by the UBL are slower than

+ * needed by MT29F16G08FAA chips ... EMIF.A1CR is 0x40400204

+ * but could be 0x0400008c for about 25% faster page reads.

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index b2e7f9c63bc5..d9d40450bdc5 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c

#define DM644X_EVM_MDIO_FREQUENCY (2200000) /* PHY bus frequency */

@@ -436,45 +438,15 @@ static struct pcf857x_platform_data pcf_data_u35 = {

-static void at24_setup(struct memory_accessor *mem_acc, void *context)

- if (at24_mem_acc->read(at24_mem_acc, mac_addr, 0x7f00, 6) == 6) {

-int dm6446evm_eeprom_read(void *buf, off_t off, size_t count)

- return at24_mem_acc->read(at24_mem_acc, buf, off, count);

-int dm6446evm_eeprom_write(void *buf, off_t off, size_t count)

- return at24_mem_acc->write(at24_mem_acc, buf, off, count);

* MSP430 supports RTC, card detection, input from IR remote, and

* a bit more. It triggers interrupts on GPIO(7) from pressing

@@ -545,6 +517,27 @@ static int dm6444evm_msp430_get_pins(void)

+static struct davinci_mmc_config dm6446evm_mmc_config = {

@@ -598,7 +591,6 @@ static struct davinci_uart_config uart_config __initdata = {

@@ -639,6 +631,7 @@ static int davinci_phy_fixup(struct phy_device *phydev)

@@ -671,8 +664,13 @@ static __init void davinci_evm_init(void)

+ soc_info->emac_pdata->mdio_max_freq = DM644X_EVM_MDIO_FREQUENCY;

phy_register_fixup_for_uid(LXT971_PHY_ID, LXT971_PHY_MASK,

diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
new file mode 100644
index 000000000000..e17de6352624
--- /dev/null
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c

+ * This file is licensed under the terms of the GNU General Public License

+ * version 2. This program is licensed "as is" without any warranty of any

+/**************************************************************************

+ **************************************************************************/

+#define DM646X_EVM_MDIO_FREQUENCY (2200000) /* PHY bus frequency */

+static struct davinci_uart_config uart_config __initdata = {

+static __initconst struct gpio_led_platform_data evm_led_data = {

+static int evm_led_setup(struct i2c_client *client, int gpio,

+static int evm_led_teardown(struct i2c_client *client, int gpio,

+static int evm_sw_gpio[4] = { -EINVAL, -EINVAL, -EINVAL, -EINVAL };

+static int evm_sw_setup(struct i2c_client *client, int gpio,

+static int evm_sw_teardown(struct i2c_client *client, int gpio,

+static int evm_pcf_setup(struct i2c_client *client, int gpio,

+static int evm_pcf_teardown(struct i2c_client *client, int gpio,

+/* Most of this EEPROM is unused, but U-Boot uses some data:

+ i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));

+ soc_info->emac_pdata->mdio_max_freq = DM646X_EVM_MDIO_FREQUENCY;

diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
new file mode 100644
index 000000000000..748a8e48541e
--- /dev/null
+++ b/arch/arm/mach-davinci/board-sffsdr.c

+ * Based on DV-EVM platform, original copyright follows:

+ * This program is free software; you can redistribute it and/or modify

+ * it under the terms of the GNU General Public License as published by

+ * the Free Software Foundation; either version 2 of the License, or

+ * This program is distributed in the hope that it will be useful,

+ * but WITHOUT ANY WARRANTY; without even the implied warranty of

+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

+ * You should have received a copy of the GNU General Public License

+ * along with this program; if not, write to the Free Software

+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

+#define SFFSDR_MDIO_FREQUENCY (2200000) /* PHY bus frequency */

+struct mtd_partition davinci_sffsdr_nandflash_partition[] = {

+static struct flash_platform_data davinci_sffsdr_nandflash_data = {

+ .nr_parts = ARRAY_SIZE(davinci_sffsdr_nandflash_partition),

+static struct resource davinci_sffsdr_nandflash_resource[] = {

+static struct platform_device davinci_sffsdr_nandflash_device = {

+ .num_resources = ARRAY_SIZE(davinci_sffsdr_nandflash_resource),

+ i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));

+static struct platform_device *davinci_sffsdr_devices[] __initdata = {

+static struct davinci_uart_config uart_config __initdata = {

+ soc_info->emac_pdata->mdio_max_freq = SFFSDR_MDIO_FREQUENCY;

+ setup_usb(0, 0); /* We support only peripheral mode. */

+ /* Maintainer: Hugo Villeneuve hugo.villeneuve@lyrtech.com */

diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index f0baaa15a57e..39bf321d70a2 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c

@@ -42,7 +42,8 @@ static void __clk_enable(struct clk *clk)

@@ -50,7 +51,8 @@ static void __clk_disable(struct clk *clk)

@@ -164,11 +166,11 @@ static int __init clk_disable_unused(void)

+ if (!davinci_psc_is_clk_active(ck->psc_ctlr, ck->lpsc))

+ davinci_psc_config(psc_domain(ck), ck->psc_ctlr, ck->lpsc, 0);

diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
index 35736ec202f8..27233cb4a2fb 100644
--- a/arch/arm/mach-davinci/clock.h
+++ b/arch/arm/mach-davinci/clock.h

diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
new file mode 100644
index 000000000000..61ede19c6b54
--- /dev/null
+++ b/arch/arm/mach-davinci/common.c

+ * 2009 (c) MontaVista Software, Inc. This file is licensed under

+ * the terms of the GNU General Public License version 2. This program

+ * is licensed "as is" without any warranty of any kind, whether express

+void davinci_get_mac_addr(struct memory_accessor *mem_acc, void *context)

+ char *mac_addr = davinci_soc_info.emac_pdata->mac_addr;

+ if (mem_acc->read(mem_acc, mac_addr, offset, ETH_ALEN) == ETH_ALEN)

+static struct davinci_id * __init davinci_get_id(u32 jtag_id)

+ for (i = 0, dip = davinci_soc_info.ids; i < davinci_soc_info.ids_num;

+ if ((dip->part_no == part_no) && (dip->variant == variant))

+void __init davinci_common_init(struct davinci_soc_info *soc_info)

+ memcpy(&davinci_soc_info, soc_info, sizeof(struct davinci_soc_info));

+ if (davinci_soc_info.io_desc && (davinci_soc_info.io_desc_num > 0))

+ * Normally devicemaps_init() would flush caches and tlb after

+ * mdesc->map_io(), but we must also do it here because of the CPU

+ * We want to check CPU revision early for cpu_is_xxxx() macros.

+ * IO space mapping must be initialized before we can do that.

+ davinci_soc_info.jtag_id = __raw_readl(davinci_soc_info.jtag_id_base);

+ pr_info("DaVinci %s variant 0x%x\n", dip->name, dip->variant);

+ pr_err("davinci_common_init: SoC Initialization failed\n");

diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
new file mode 100644
index 000000000000..96c8e97a7deb
--- /dev/null
+++ b/arch/arm/mach-davinci/cp_intc.c

+ * TI Common Platform Interrupt Controller (cp_intc) driver

+ * This file is licensed under the terms of the GNU General Public License

+ * version 2. This program is licensed "as is" without any warranty of any

+static inline unsigned int cp_intc_read(unsigned offset)

+static inline void cp_intc_write(unsigned long value, unsigned offset)

+ /* XXX don't know why we need to disable nIRQ here... */

+static int cp_intc_set_irq_type(unsigned int irq, unsigned int flow_type)

+ unsigned polarity = cp_intc_read(CP_INTC_SYS_POLARITY(reg));

+void __init cp_intc_init(void __iomem *base, unsigned short num_irq,

+ * Priority is determined by host channel: lower channel number has

+ * higher priority i.e. channel 0 has highest priority and channel 31

+ num_reg = (num_irq + 3) >> 2; /* 4 channels per register */

+ * Default everything to channel 15 if priority not specified.

+ * Note that channel 0-1 are mapped to nFIQ and channels 2-31

diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index a31370b93dd2..de16f347566a 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c

@@ -54,3 +60,208 @@ void __init davinci_init_i2c(struct davinci_i2c_platform_data *pdata)

+#if defined(CONFIG_MMC_DAVINCI) || defined(CONFIG_MMC_DAVINCI_MODULE)

+void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config)

+ /* REVISIT: update PINMUX, ARM_IRQMUX, and EDMA_EVTMUX here too;

+ * for example if MMCSD1 is used for SDIO, maybe DAT2 is unused.

+ * FIXME dm6441 (no MMC/SD), dm357 (one), and dm335 (two) are

+ mmcsd0_resources[0].end = DM355_MMCSD0_BASE + SZ_4K - 1;

+void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config)

+/*-------------------------------------------------------------------------*/

+ wdt_resources[0].start = (resource_size_t)soc_info->wdt_base;

+ wdt_resources[0].end = (resource_size_t)soc_info->wdt_base + SZ_1K - 1;

+/*-------------------------------------------------------------------------*/

+struct davinci_timer_instance davinci_timer_instance[2] = {

+/*-------------------------------------------------------------------------*/

+ /* please keep these calls, and their implementations above,

+ * in alphabetical order so they're easier to sort through.

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
new file mode 100644
index 000000000000..baaaf328de2e
--- /dev/null
+++ b/arch/arm/mach-davinci/dm355.c

+ * 2007 (c) Deep Root Systems, LLC. This file is licensed under

+ * the terms of the GNU General Public License version 2. This program

+ * is licensed "as is" without any warranty of any kind, whether express

+ /* NOTE: clkout1 can be externally gated by muxing GPIO-18 */

+ /* NOTE: clkout3 can be externally gated by muxing GPIO-16 */

+ * .lpsc = DAVINCI_LPSC_DDR_EMIF, .parent = &sysclk2_clk,

+ .usecount = 1, /* REVISIT: why cant' this be disabled? */

+/*----------------------------------------------------------------------*/

+static u8 dm355_default_priorities[DAVINCI_N_AINTC_IRQ] = {

+/*----------------------------------------------------------------------*/

+ /* MT_MEMORY_NONCACHED requires supersection alignment */

+/* Contents of JTAG ID register used to identify exact cpu type */

+ * T0_BOT: Timer 0, bottom: clockevent source for hrtimers

+ * T0_TOP: Timer 0, top : clocksource for generic timekeeping

+ * T1_BOT: Timer 1, bottom: (used by DSP in TI DSPLink code)

+static struct plat_serial8250_port dm355_serial_platform_data[] = {

+static struct davinci_soc_info davinci_soc_info_dm355 = {

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index d428ef192eac..fb5449b3c97b 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c

@@ -312,7 +319,14 @@ struct davinci_clk dm644x_clks[] = {

-#if defined(CONFIG_TI_DAVINCI_EMAC) || defined(CONFIG_TI_DAVINCI_EMAC_MODULE)

@@ -330,11 +344,15 @@ static struct resource dm644x_emac_resources[] = {

@@ -343,6 +361,7 @@ static struct platform_device dm644x_emac_device = {

@@ -383,8 +402,76 @@ MUX_CFG(DM644X, RGB666, 0, 22, 1, 1, true)

+/* FIQ are pri 0-1; otherwise 2-7, with 7 lowest priority */

+static u8 dm644x_default_priorities[DAVINCI_N_AINTC_IRQ] = {

/*----------------------------------------------------------------------*/

@@ -444,10 +531,118 @@ static struct platform_device dm644x_edma_device = {

/*----------------------------------------------------------------------*/

+ /* MT_MEMORY_NONCACHED requires supersection alignment */

+/* Contents of JTAG ID register used to identify exact cpu type */

+ * T0_BOT: Timer 0, bottom: clockevent source for hrtimers

+ * T0_TOP: Timer 0, top : clocksource for generic timekeeping

+ * T1_BOT: Timer 1, bottom: (used by DSP in TI DSPLink code)

+static struct plat_serial8250_port dm644x_serial_platform_data[] = {

+static struct davinci_soc_info davinci_soc_info_dm644x = {

- davinci_mux_register(dm644x_pins, ARRAY_SIZE(dm644x_pins));

@@ -456,6 +651,7 @@ static int __init dm644x_init_devices(void)

diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
new file mode 100644
index 000000000000..334f0711e0f5
--- /dev/null
+++ b/arch/arm/mach-davinci/dm646x.c

+ * 2007 (c) Deep Root Systems, LLC. This file is licensed under

+ * the terms of the GNU General Public License version 2. This program

+ * is licensed "as is" without any warranty of any kind, whether express

+ .flags = ALWAYS_ENABLED, /* no LPSC, always enabled; c.f. spruep9a */

+static u8 dm646x_default_priorities[DAVINCI_N_AINTC_IRQ] = {

+/*----------------------------------------------------------------------*/

+ /* MT_MEMORY_NONCACHED requires supersection alignment */

+/* Contents of JTAG ID register used to identify exact cpu type */

+ * T0_BOT: Timer 0, bottom: clockevent source for hrtimers

+ * T0_TOP: Timer 0, top : clocksource for generic timekeeping

+ * T1_BOT: Timer 1, bottom: (used by DSP in TI DSPLink code)

+static struct plat_serial8250_port dm646x_serial_platform_data[] = {

+static struct davinci_soc_info davinci_soc_info_dm646x = {

diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 1aba41c6351e..1b6532159c58 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c

static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];

static struct gpio_controller __iomem * __init gpio2controller(unsigned gpio)

/*--------------------------------------------------------------------------*/

@@ -115,23 +115,16 @@ davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)

- /* The gpio banks conceptually expose a segmented bitmap,

+ * The gpio banks conceptually expose a segmented bitmap,

@@ -157,6 +150,7 @@ static int __init davinci_gpio_setup(void)

@@ -187,10 +181,15 @@ static void gpio_irq_enable(unsigned irq)

struct gpio_controller *__iomem g = get_irq_chip_data(irq);

+ status &= IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING;

@@ -205,10 +204,13 @@ static int gpio_irq_type(unsigned irq, unsigned trigger)

@@ -230,6 +232,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)

@@ -268,17 +271,15 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)

@@ -318,11 +319,9 @@ static int __init davinci_gpio_irq_setup(void)

/* BINTEN -- per-bank interrupt enable. genirq would also let these

printk(KERN_INFO "DaVinci: %d gpio irqs\n", irq - gpio_to_irq(0));

diff --git a/arch/arm/mach-davinci/id.c b/arch/arm/mach-davinci/id.c
deleted file mode 100644
index 018b994cd794..000000000000
--- a/arch/arm/mach-davinci/id.c
+++ /dev/null

- * This program is free software; you can redistribute it and/or modify

- * it under the terms of the GNU General Public License version 2 as

- u32 type; /* Cpu id bits [31:8], cpu class bits [7:0] */

diff --git a/arch/arm/mach-davinci/include/mach/board-dm6446evm.h b/arch/arm/mach-davinci/include/mach/board-dm6446evm.h
deleted file mode 100644
index 3216f21c1238..000000000000
--- a/arch/arm/mach-davinci/include/mach/board-dm6446evm.h
+++ /dev/null

- * 2007 (c) Deep Root Systems, LLC. This file is licensed under

- * the terms of the GNU General Public License version 2. This program

- * is licensed "as is" without any warranty of any kind, whether express

-int dm6446evm_eeprom_read(char *buf, off_t off, size_t count);

-int dm6446evm_eeprom_write(char *buf, off_t off, size_t count);

diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 191770976250..a1f03b606d8f 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h

extern void setup_usb(unsigned mA, unsigned potpgt_msec);

@@ -25,4 +26,56 @@ extern void setup_usb(unsigned mA, unsigned potpgt_msec);

extern void setup_usb(unsigned mA, unsigned potpgt_msec);

+extern void davinci_common_init(struct davinci_soc_info *soc_info);

+/* standard place to map on-chip SRAMs; they *may* support DMA */

diff --git a/arch/arm/mach-davinci/include/mach/cp_intc.h b/arch/arm/mach-davinci/include/mach/cp_intc.h
new file mode 100644
index 000000000000..c4d27eec8064
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/cp_intc.h

+ * TI Common Platform Interrupt Controller (cp_intc) definitions

+ * This file is licensed under the terms of the GNU General Public License

+ * version 2. This program is licensed "as is" without any warranty of any

+#define CP_INTC_SYS_SECURE_ENABLE(n) (0x1000 + (n << 2))

+#define CP_INTC_HOST_NESTING_LEVEL(n) (0x1100 + (n << 2))

+void __init cp_intc_init(void __iomem *base, unsigned short num_irq,

diff --git a/arch/arm/mach-davinci/include/mach/cputype.h b/arch/arm/mach-davinci/include/mach/cputype.h
index 27cfb1b3a662..d12a5ed2959a 100644
--- a/arch/arm/mach-davinci/include/mach/cputype.h
+++ b/arch/arm/mach-davinci/include/mach/cputype.h

+/* Can use lower 16 bits of cpu id for a variant when required */

diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S
index e6c0f0d5d062..de3fc2182b47 100644
--- a/arch/arm/mach-davinci/include/mach/debug-macro.S
+++ b/arch/arm/mach-davinci/include/mach/debug-macro.S

+ * Jan 2009 Chaithrika U S Added senduart, busyuart, waituart

diff --git a/arch/arm/mach-davinci/include/mach/dm355.h b/arch/arm/mach-davinci/include/mach/dm355.h
new file mode 100644
index 000000000000..54903b72438e
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/dm355.h

+ * 2007 (c) Deep Root Systems, LLC. This file is licensed under

+ * the terms of the GNU General Public License version 2. This program

+ * is licensed "as is" without any warranty of any kind, whether express

diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h
index 3dcb9f4e58b4..15d42b92a8c9 100644
--- a/arch/arm/mach-davinci/include/mach/dm644x.h
+++ b/arch/arm/mach-davinci/include/mach/dm644x.h

diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h
new file mode 100644
index 000000000000..1fc764c8646e
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h

+ * 2007 (c) Deep Root Systems, LLC. This file is licensed under

+ * the terms of the GNU General Public License version 2. This program

+ * is licensed "as is" without any warranty of any kind, whether express

diff --git a/arch/arm/mach-davinci/include/mach/edma.h b/arch/arm/mach-davinci/include/mach/edma.h
index f6fc5396dafc..24a379239d7f 100644
--- a/arch/arm/mach-davinci/include/mach/edma.h
+++ b/arch/arm/mach-davinci/include/mach/edma.h

@@ -208,10 +208,6 @@ void edma_clear_event(unsigned channel);

diff --git a/arch/arm/mach-davinci/include/mach/emac.h b/arch/arm/mach-davinci/include/mach/emac.h
new file mode 100644
index 000000000000..beff4fb7c845
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/emac.h

+ * 2007 (c) Deep Root Systems, LLC. This file is licensed under

+ * the terms of the GNU General Public License version 2. This program

+ * is licensed "as is" without any warranty of any kind, whether express

+void davinci_get_mac_addr(struct memory_accessor *mem_acc, void *context);

diff --git a/arch/arm/mach-davinci/include/mach/entry-macro.S b/arch/arm/mach-davinci/include/mach/entry-macro.S
index 039b84f933b3..fbdebc7cb409 100644
--- a/arch/arm/mach-davinci/include/mach/entry-macro.S
+++ b/arch/arm/mach-davinci/include/mach/entry-macro.S

diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h
index efe3281364e6..ae0745568316 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h

@@ -67,15 +68,16 @@ static inline struct gpio_controller *__iomem

@@ -142,13 +144,13 @@ static inline int gpio_to_irq(unsigned gpio)

diff --git a/arch/arm/mach-davinci/include/mach/irqs.h b/arch/arm/mach-davinci/include/mach/irqs.h
index 18066074c995..bc5d6aaa69a3 100644
--- a/arch/arm/mach-davinci/include/mach/irqs.h
+++ b/arch/arm/mach-davinci/include/mach/irqs.h

diff --git a/arch/arm/mach-davinci/include/mach/memory.h b/arch/arm/mach-davinci/include/mach/memory.h
index 86c25c7f3ce3..c712c7cdf38f 100644
--- a/arch/arm/mach-davinci/include/mach/memory.h
+++ b/arch/arm/mach-davinci/include/mach/memory.h

**************************************************************************/

-#define DAVINCI_IRAM_BASE 0x00008000 /* ARM Internal RAM */

diff --git a/arch/arm/mach-davinci/include/mach/mmc.h b/arch/arm/mach-davinci/include/mach/mmc.h
new file mode 100644
index 000000000000..5a85e24f3673
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/mmc.h

+ /* wires == 0 is equivalent to wires == 4 (4-bit parallel) */

+ /* any additional host capabilities: OR'd in to mmc->f_caps */

+void davinci_setup_mmc(int module, struct davinci_mmc_config *config);

diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
index bae22cb3e27b..27378458542f 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h

-extern int davinci_mux_register(const struct mux_config *pins,

/* boot loader does it all (no warnings from CONFIG_DAVINCI_MUX_WARNINGS) */

-static inline int davinci_mux_register(const struct mux_config *pins,

static inline int davinci_cfg_reg(unsigned long reg_cfg) { return 0; }

diff --git a/arch/arm/mach-davinci/include/mach/psc.h b/arch/arm/mach-davinci/include/mach/psc.h
index 55a90d419fac..ab8a2586d1cc 100644
--- a/arch/arm/mach-davinci/include/mach/psc.h
+++ b/arch/arm/mach-davinci/include/mach/psc.h

-extern void davinci_psc_config(unsigned int domain, unsigned int id,

+extern int davinci_psc_is_clk_active(unsigned int ctlr, unsigned int id);

+extern void davinci_psc_config(unsigned int domain, unsigned int ctlr,

diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h
index 632847d74a1c..794fa5cf93c1 100644
--- a/arch/arm/mach-davinci/include/mach/serial.h
+++ b/arch/arm/mach-davinci/include/mach/serial.h

-extern void davinci_serial_init(struct davinci_uart_config *);

+extern int davinci_serial_init(struct davinci_uart_config *);

diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
new file mode 100644
index 000000000000..111f7cc71e07
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/sram.h

+ * This program is free software; you can redistribute it and/or modify

+ * it under the terms of the GNU General Public License version 2 as

+/* ARBITRARY: SRAM allocations are multiples of this 2^N size */

+ * SRAM allocations return a CPU virtual address, or NULL on error.

+ * If a DMA address is requested and the SRAM supports DMA, its

+ * Errors include SRAM memory not being available, and requesting

diff --git a/arch/arm/mach-davinci/include/mach/time.h b/arch/arm/mach-davinci/include/mach/time.h
new file mode 100644
index 000000000000..1c971d8d8ba8
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/time.h

+ * Author: Kevin Hilman, MontaVista Software, Inc. <source@mvista.com>

+ * 2007 (c) MontaVista Software, Inc. This file is licensed under

+ * the terms of the GNU General Public License version 2. This program

+ * is licensed "as is" without any warranty of any kind, whether express

+extern struct davinci_timer_instance davinci_timer_instance[];

diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 8c165def37b6..1e27475f9a23 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h

+ /* Add logic here for new platforms, using __macine_arch_type */

- volatile u32 *uart = (volatile void *) DAVINCI_UART0_BASE;

diff --git a/arch/arm/mach-davinci/io.c b/arch/arm/mach-davinci/io.c
index a548abb513e2..49912b48b1b0 100644
--- a/arch/arm/mach-davinci/io.c
+++ b/arch/arm/mach-davinci/io.c

- * The machine specific code may provide the extra mapping besides the

- iotable_init(davinci_io_desc, ARRAY_SIZE(davinci_io_desc));

- /* Normally devicemaps_init() would flush caches and tlb after

- * mdesc->map_io(), but we must also do it here because of the CPU

- /* We want to check CPU revision early for cpu_is_xxxx() macros.

- * IO space mapping must be initialized before we can do that.

#define BETWEEN(p, st, sz) ((p) >= (st) && (p) < ((st) + (sz)))

#define XLATE(p, pst, vst) ((void __iomem *)((p) - (pst) + (vst)))

diff --git a/arch/arm/mach-davinci/irq.c b/arch/arm/mach-davinci/irq.c
index 5a324c90e291..af92ffee8471 100644
--- a/arch/arm/mach-davinci/irq.c
+++ b/arch/arm/mach-davinci/irq.c

static inline void davinci_irq_writel(unsigned long value, int offset)

@@ -113,217 +110,11 @@ static struct irq_chip davinci_irq_chip_0 = {

-/* FIQ are pri 0-1; otherwise 2-7, with 7 lowest priority */

-static const u8 dm644x_default_priorities[DAVINCI_N_AINTC_IRQ] __initdata = {

-static const u8 dm646x_default_priorities[DAVINCI_N_AINTC_IRQ] = {

-static const u8 dm355_default_priorities[DAVINCI_N_AINTC_IRQ] = {

+ const u8 *davinci_def_priorities = davinci_soc_info.intc_irq_prios;

diff --git a/arch/arm/mach-davinci/mux.c b/arch/arm/mach-davinci/mux.c
index bbba0b247a44..d310f579aa85 100644
--- a/arch/arm/mach-davinci/mux.c
+++ b/arch/arm/mach-davinci/mux.c

-int __init davinci_mux_register(const struct mux_config *pins,

@@ -40,23 +29,24 @@ int __init davinci_mux_register(const struct mux_config *pins,

int __init_or_module davinci_cfg_reg(const unsigned long index)

- void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);

diff --git a/arch/arm/mach-davinci/psc.c b/arch/arm/mach-davinci/psc.c
index 84171abf5f7b..a78b657e916e 100644
--- a/arch/arm/mach-davinci/psc.c
+++ b/arch/arm/mach-davinci/psc.c

+int __init davinci_psc_is_clk_active(unsigned int ctlr, unsigned int id)

- void __iomem *psc_base = IO_ADDRESS(DAVINCI_PWR_SLEEP_CNTRL_BASE);

+ if (!soc_info->psc_bases || (ctlr >= soc_info->psc_bases_num)) {

-void davinci_psc_config(unsigned int domain, unsigned int id, char enable)

+void davinci_psc_config(unsigned int domain, unsigned int ctlr,

- void __iomem *psc_base = IO_ADDRESS(DAVINCI_PWR_SLEEP_CNTRL_BASE);

u32 next_state = enable ? 0x3 : 0x2; /* 0x3 enables, 0x2 disables */

+ if (!soc_info->psc_bases || (ctlr >= soc_info->psc_bases_num)) {

diff --git a/arch/arm/mach-davinci/serial.c b/arch/arm/mach-davinci/serial.c
index 695075796522..c530c7333d0a 100644
--- a/arch/arm/mach-davinci/serial.c
+++ b/arch/arm/mach-davinci/serial.c

static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,

@@ -49,44 +51,6 @@ static inline void serial_write_reg(struct plat_serial8250_port *p, int offset,

-static struct plat_serial8250_port serial_platform_data[] = {

static void __init davinci_serial_reset(struct plat_serial8250_port *p)

@@ -106,35 +70,22 @@ static void __init davinci_serial_reset(struct plat_serial8250_port *p)

-void __init davinci_serial_init(struct davinci_uart_config *info)

+int __init davinci_serial_init(struct davinci_uart_config *info)

+ * You have to mux them off in device drivers later on if not needed.

- struct plat_serial8250_port *p = serial_platform_data + i;

@@ -147,11 +98,6 @@ void __init davinci_serial_init(struct davinci_uart_config *info)

diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
new file mode 100644
index 000000000000..db54b2a66b4d
--- /dev/null
+++ b/arch/arm/mach-davinci/sram.c

+ * This program is free software; you can redistribute it and/or modify

+ * it under the terms of the GNU General Public License as published by

+ * the Free Software Foundation; either version 2 of the License, or

+ * REVISIT This supports CPU and DMA access to/from SRAM, but it

+ * doesn't (yet?) support some other notable uses of SRAM: as TCM

+ * for data and/or instructions; and holding code needed to enter

+ sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);

diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 494e01bff5c3..0884ca57bfb0 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c

* This driver configures the 2 64-bit count-up timers as 4 independent

- * T0_BOT: Timer 0, bottom: clockevent source for hrtimers

- * T0_TOP: Timer 0, top : clocksource for generic timekeeping

- * T1_BOT: Timer 1, bottom: (used by DSP in TI DSPLink code)

+#define USING_COMPARE(t) ((t)->opts & TIMER_OPTS_USE_COMPARE)

+ int event_timer = ID_TO_TIMER(timers[TID_CLOCKEVENT].id);

+ * Next interrupt should be the current time reg value plus

+ * the new period (using 32-bit unsigned addition/wrapping

+ * is setup to count to 2^32-1 before wrapping around to 0.

+ __raw_writel(__raw_readl(t->base + t->tim_off) + t->period,

- u32 phys_bases[] = {DAVINCI_TIMER0_BASE, DAVINCI_TIMER1_BASE};

+ struct davinci_timer_instance *dtip = soc_info->timer_info->timers;

@@ -214,33 +234,33 @@ static void __init timer_init(void)

@@ -255,7 +275,6 @@ static cycle_t read_cycles(struct clocksource *cs)

@@ -284,15 +303,18 @@ static void davinci_set_mode(enum clock_event_mode mode,

@@ -300,7 +322,6 @@ static void davinci_set_mode(enum clock_event_mode mode,

.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,

@@ -311,10 +332,42 @@ static struct clock_event_device clockevent_davinci = {

+ * If using same timer for both clock events & clocksource,

+ * a compare register must be used to generate an event interrupt.

+ * This is equivalent to a oneshot timer only (not periodic).

+ pr_warning("davinci_timer_init: Invalid timer instance"

@@ -325,6 +378,7 @@ static void __init davinci_timer_init(void)

@@ -332,12 +386,12 @@ static void __init davinci_timer_init(void)

+ clockevent_davinci.name = id_to_name[timers[TID_CLOCKEVENT].id];

clockevent_davinci.mult = div_sc(davinci_clock_tick_rate, NSEC_PER_SEC,

diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
index 56bddcef6905..d7291c682a64 100644
--- a/arch/arm/mach-ep93xx/Kconfig
+++ b/arch/arm/mach-ep93xx/Kconfig

+ Select this option if you want support for EP93xx boards with the

+ Say 'Y' here if you want your kernel to support the Cirrus

Say 'Y' here if you want your kernel to support the Cirrus

Say 'Y' here if you want your kernel to support the Glomation

diff --git a/arch/arm/mach-ep93xx/Makefile b/arch/arm/mach-ep93xx/Makefile
index 9522e205b73f..eae6199a9891 100644
--- a/arch/arm/mach-ep93xx/Makefile
+++ b/arch/arm/mach-ep93xx/Makefile

diff --git a/arch/arm/mach-ep93xx/Makefile.boot b/arch/arm/mach-ep93xx/Makefile.boot
index d5561ad15bad..27a085a8f12a 100644
--- a/arch/arm/mach-ep93xx/Makefile.boot
+++ b/arch/arm/mach-ep93xx/Makefile.boot

+ zreladdr-$(CONFIG_EP93XX_SDCE3_SYNC_PHYS_OFFSET) := 0x00008000

+params_phys-$(CONFIG_EP93XX_SDCE3_SYNC_PHYS_OFFSET) := 0x00000100

+ zreladdr-$(CONFIG_EP93XX_SDCE0_PHYS_OFFSET) := 0xc0008000

+params_phys-$(CONFIG_EP93XX_SDCE0_PHYS_OFFSET) := 0xc0000100

diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c
index e8ebeaea6c48..6c4c1633ed12 100644
--- a/arch/arm/mach-ep93xx/clock.c
+++ b/arch/arm/mach-ep93xx/clock.c

+ * The EP93xx has two external crystal oscillators. To generate the

+ * required high-frequency clocks, the processor uses two phase-locked-

+ * loops (PLLs) to multiply the incoming external clock signal to much

+ * higher frequencies that are then divided down by programmable dividers

+ * to produce the needed clocks. The PLLs operate independently of one

__raw_writel(value & ~clk->enable_mask, clk->enable_reg);

@@ -162,7 +215,7 @@ static unsigned long calc_pll_rate(u32 config_word)

@@ -195,7 +248,7 @@ static int __init ep93xx_clock_init(void)

@@ -206,7 +259,7 @@ static int __init ep93xx_clock_init(void)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index ae24486f858a..204dc5cbd0b8 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c

@@ -155,7 +155,7 @@ static unsigned char gpio_int_unmasked[3];

static const u8 int_type1_register_offset[3] = { 0x90, 0xac, 0x4c };

@@ -192,11 +192,11 @@ void ep93xx_gpio_int_debounce(unsigned int irq, int enable)

- vic_init((void *)EP93XX_VIC1_BASE, 0, EP93XX_VIC1_VALID_IRQ_MASK);

- vic_init((void *)EP93XX_VIC2_BASE, 32, EP93XX_VIC2_VALID_IRQ_MASK);

+ vic_init((void *)EP93XX_VIC1_BASE, 0, EP93XX_VIC1_VALID_IRQ_MASK, 0);

+ vic_init((void *)EP93XX_VIC2_BASE, 32, EP93XX_VIC2_VALID_IRQ_MASK, 0);

gpio_irq <= gpio_to_irq(EP93XX_GPIO_LINE_MAX_IRQ); ++gpio_irq) {

@@ -450,10 +450,19 @@ static struct amba_device uart3_device = {

diff --git a/arch/arm/mach-ep93xx/edb9302.c b/arch/arm/mach-ep93xx/edb9302.c
deleted file mode 100644
index 8bf8d7c78f1a..000000000000
--- a/arch/arm/mach-ep93xx/edb9302.c
+++ /dev/null

- * This program is free software; you can redistribute it and/or modify

- * it under the terms of the GNU General Public License as published by

- * the Free Software Foundation; either version 2 of the License, or (at

-MACHINE_START(EDB9302, "Cirrus Logic EDB9302 Evaluation Board")

- /* Maintainer: George Kashperko <george@chas.com.ua> */

- .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

diff --git a/arch/arm/mach-ep93xx/edb9302a.c b/arch/arm/mach-ep93xx/edb9302a.c
deleted file mode 100644
index a352c57c7b46..000000000000
--- a/arch/arm/mach-ep93xx/edb9302a.c
+++ /dev/null

- * This program is free software; you can redistribute it and/or modify

- * it under the terms of the GNU General Public License as published by

- * the Free Software Foundation; either version 2 of the License, or (at

-static struct physmap_flash_data edb9302a_flash_data = {

-MACHINE_START(EDB9302A, "Cirrus Logic EDB9302A Evaluation Board")

- /* Maintainer: Lennert Buytenhek <buytenh@wantstofly.org> */

- .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

diff --git a/arch/arm/mach-ep93xx/edb9307.c b/arch/arm/mach-ep93xx/edb9307.c
deleted file mode 100644
index 5ab22f63a4eb..000000000000
--- a/arch/arm/mach-ep93xx/edb9307.c
+++ /dev/null

- * This program is free software; you can redistribute it and/or modify

- * it under the terms of the GNU General Public License as published by

- * the Free Software Foundation; either version 2 of the License, or (at

-MACHINE_START(EDB9307, "Cirrus Logic EDB9307 Evaluation Board")

- .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

diff --git a/arch/arm/mach-ep93xx/edb9307a.c b/arch/arm/mach-ep93xx/edb9307a.c
deleted file mode 100644
index 6171167d3315..000000000000
--- a/arch/arm/mach-ep93xx/edb9307a.c
+++ /dev/null

- * This program is free software; you can redistribute it and/or modify

- * it under the terms of the GNU General Public License as published by

- * the Free Software Foundation; either version 2 of the License, or (at

-static struct physmap_flash_data edb9307a_flash_data = {

-static struct i2c_board_info __initdata edb9307a_i2c_data[] = {

- * The I2C signals are also routed to the Expansion Connector (J4)

- ep93xx_init_i2c(edb9307a_i2c_data, ARRAY_SIZE(edb9307a_i2c_data));

-MACHINE_START(EDB9307A, "Cirrus Logic EDB9307A Evaluation Board")

- /* Maintainer: H Hartley Sweeten <hsweeten@visionengravers.com> */

- .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

diff --git a/arch/arm/mach-ep93xx/edb9312.c b/arch/arm/mach-ep93xx/edb9312.c
deleted file mode 100644
index d7179f66d804..000000000000
--- a/arch/arm/mach-ep93xx/edb9312.c
+++ /dev/null

- * This program is free software; you can redistribute it and/or modify

- * it under the terms of the GNU General Public License as published by

- * the Free Software Foundation; either version 2 of the License, or (at

-MACHINE_START(EDB9312, "Cirrus Logic EDB9312 Evaluation Board")

- /* Maintainer: Toufeeq Hussain <toufeeq_hussain@infosys.com> */

- .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

diff --git a/arch/arm/mach-ep93xx/edb9315.c b/arch/arm/mach-ep93xx/edb9315.c
deleted file mode 100644
index 025af6eaca10..000000000000
--- a/arch/arm/mach-ep93xx/edb9315.c
+++ /dev/null

- * This program is free software; you can redistribute it and/or modify

- * it under the terms of the GNU General Public License as published by

- * the Free Software Foundation; either version 2 of the License, or (at

-MACHINE_START(EDB9315, "Cirrus Logic EDB9315 Evaluation Board")

- /* Maintainer: Lennert Buytenhek <buytenh@wantstofly.org> */

- .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

diff --git a/arch/arm/mach-ep93xx/edb9315a.c b/arch/arm/mach-ep93xx/edb9315a.c
deleted file mode 100644
index 4c9cc8a39f5c..000000000000
--- a/arch/arm/mach-ep93xx/edb9315a.c
+++ /dev/null

- * This program is free software; you can redistribute it and/or modify

- * it under the terms of the GNU General Public License as published by

- * the Free Software Foundation; either version 2 of the License, or (at

-static struct physmap_flash_data edb9315a_flash_data = {

-MACHINE_START(EDB9315A, "Cirrus Logic EDB9315A Evaluation Board")

- /* Maintainer: Lennert Buytenhek <buytenh@wantstofly.org> */

- .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
new file mode 100644
index 000000000000..e9e45b92457e
--- /dev/null
+++ b/arch/arm/mach-ep93xx/edb93xx.c

+ * This program is free software; you can redistribute it and/or modify

+ * it under the terms of the GNU General Public License as published by

+ * the Free Software Foundation; either version 2 of the License, or (at

+static void __init __edb93xx_register_flash(unsigned int width,

+ __edb93xx_register_flash(4, EP93XX_CS6_PHYS_BASE, SZ_32M);

+ __edb93xx_register_flash(2, EP93XX_CS6_PHYS_BASE, SZ_16M);

+static struct i2c_board_info __initdata edb93xxa_i2c_data[] = {

+static struct i2c_board_info __initdata edb93xx_i2c_data[] = {

+ } else if (machine_is_edb9307() || machine_is_edb9312() ||

+MACHINE_START(EDB9301, "Cirrus Logic EDB9301 Evaluation Board")

+ /* Maintainer: H Hartley Sweeten <hsweeten@visionengravers.com> */

+ .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

+MACHINE_START(EDB9302, "Cirrus Logic EDB9302 Evaluation Board")

+ /* Maintainer: George Kashperko <george@chas.com.ua> */

+ .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

+MACHINE_START(EDB9302A, "Cirrus Logic EDB9302A Evaluation Board")

+ /* Maintainer: Lennert Buytenhek <buytenh@wantstofly.org> */

+ .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

+MACHINE_START(EDB9307, "Cirrus Logic EDB9307 Evaluation Board")

+ .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

+MACHINE_START(EDB9307A, "Cirrus Logic EDB9307A Evaluation Board")

+ /* Maintainer: H Hartley Sweeten <hsweeten@visionengravers.com> */

+ .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

+MACHINE_START(EDB9312, "Cirrus Logic EDB9312 Evaluation Board")

+ /* Maintainer: Toufeeq Hussain <toufeeq_hussain@infosys.com> */

+ .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

+MACHINE_START(EDB9315, "Cirrus Logic EDB9315 Evaluation Board")

+ /* Maintainer: Lennert Buytenhek <buytenh@wantstofly.org> */

+ .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

+MACHINE_START(EDB9315A, "Cirrus Logic EDB9315A Evaluation Board")

+ /* Maintainer: Lennert Buytenhek <buytenh@wantstofly.org> */

+ .io_pg_offst = ((EP93XX_APB_VIRT_BASE) >> 18) & 0xfffc,

diff --git a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
index f66be12b856e..967c079180db 100644
--- a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
+++ b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h

#define EP93XX_PWM_BASE (EP93XX_APB_VIRT_BASE + 0x00110000)

#define EP93XX_RTC_BASE (EP93XX_APB_VIRT_BASE + 0x00120000)

+#define EP93XX_RTC_PHYS_BASE (EP93XX_APB_PHYS_BASE + 0x00120000)

#define EP93XX_SYSCON_BASE (EP93XX_APB_VIRT_BASE + 0x00130000)

#define EP93XX_SYSCON_POWER_STATE EP93XX_SYSCON_REG(0x00)

-#define EP93XX_SYSCON_CLOCK_CONTROL EP93XX_SYSCON_REG(0x04)

#define EP93XX_SYSCON_DEVICE_CONFIG EP93XX_SYSCON_REG(0x80)

-#define EP93XX_SYSCON_DEVICE_CONFIG_CRUNCH_ENABLE 0x00800000

+#define EP93XX_SYSCON_DEVICE_CONFIG_CRUNCH_ENABLE (1<<23)

#define EP93XX_WATCHDOG_BASE (EP93XX_APB_VIRT_BASE + 0x00140000)

diff --git a/arch/arm/mach-ep93xx/include/mach/memory.h b/arch/arm/mach-ep93xx/include/mach/memory.h
index 5c80c3c8158d..925b12ea0990 100644
--- a/arch/arm/mach-ep93xx/include/mach/memory.h
+++ b/arch/arm/mach-ep93xx/include/mach/memory.h

diff --git a/arch/arm/mach-gemini/include/mach/hardware.h b/arch/arm/mach-gemini/include/mach/hardware.h
index de6752674c05..213a4fcfeb1c 100644
--- a/arch/arm/mach-gemini/include/mach/hardware.h
+++ b/arch/arm/mach-gemini/include/mach/hardware.h

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
deleted file mode 100644
index cddd194ac6eb..000000000000
--- a/arch/arm/mach-imx/Kconfig
+++ /dev/null

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
deleted file mode 100644
index b047c7e795a9..000000000000
--- a/arch/arm/mach-imx/Makefile
+++ /dev/null

diff --git a/arch/arm/mach-imx/Makefile.boot b/arch/arm/mach-imx/Makefile.boot
deleted file mode 100644
index fd72ce5b8081..000000000000
--- a/arch/arm/mach-imx/Makefile.boot
+++ /dev/null

diff --git a/arch/arm/mach-imx/clock.c b/arch/arm/mach-imx/clock.c
deleted file mode 100644
index cf332aeb942e..000000000000
--- a/arch/arm/mach-imx/clock.c
+++ /dev/null

- * This program is free software; you can redistribute it and/or modify

- * it under the terms of the GNU General Public License as published by

- * the Free Software Foundation; either version 2 of the License, or

- * This program is distributed in the hope that it will be useful,

- * but WITHOUT ANY WARRANTY; without even the implied warranty of

- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

- * You should have received a copy of the GNU General Public License

- * along with this program; if not, write to the Free Software

- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

- * Very simple approach: We can't disable clocks, so we do

-static unsigned long imx_decode_pll(unsigned int pll, u32 f_ref)

- u32 f_ref = (CSCR & CSCR_SYSTEM_SEL) ? 16000000 : (CLK32 * 512);

diff --git a/arch/arm/mach-imx/cpufreq.c b/arch/arm/mach-imx/cpufreq.c
deleted file mode 100644
index 434b4ca0af67..000000000000
--- a/arch/arm/mach-imx/cpufreq.c
+++ /dev/null

- * - Johan Pouwelse (J.A.Pouwelse@its.tudelft.nl): initial version