---

yaml
---
r: 142219
b: refs/heads/master
c: 3d544f4
h: refs/heads/master
i:
  142217: 5e76b18
  142215: e484eaf
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: a63856252d2112e7c452696037a86ceb12f47f80
+refs/heads/master: 3d544f411f2971eb82f5c52322251eb04494542a

trunk/CREDITS

@@ -1412,8 +1412,8 @@ P: 1024D/77D4FC9B F5C5 1C20 1DFC DEC3 3107  54A4 2332 ADFC 77D4 FC9B
 D: National Language Support
 D: Linux Internationalization Project
 D: German Localization for Linux and GNU software
-S: Auf der Fittel 18
-S: 53347 Alfter
+S: Kriemhildring 12a
+S: 65795 Hattersheim am Main
 S: Germany
 
 N: Christoph Hellwig
@@ -3580,12 +3580,6 @@ N: Dirk Verworner
 D: Co-author of German book ``Linux-Kernel-Programmierung''
 D: Co-founder of Berlin Linux User Group
 
-N: Riku Voipio
-E: riku.voipio@iki.fi
-D: Author of PCA9532 LED and Fintek f75375s hwmon driver
-D: Some random ARM board patches
-S: Finland
-
 N: Patrick Volkerding
 E: volkerdi@ftp.cdrom.com
 D: Produced the Slackware distribution, updated the SVGAlib

trunk/Documentation/00-INDEX

@@ -86,8 +86,6 @@ cachetlb.txt
 	- describes the cache/TLB flushing interfaces Linux uses.
 cdrom/
 	- directory with information on the CD-ROM drivers that Linux has.
-cgroups/
-	- cgroups features, including cpusets and memory controller.
 connector/
 	- docs on the netlink based userspace<->kernel space communication mod.
 console/
@@ -100,6 +98,8 @@ cpu-load.txt
 	- document describing how CPU load statistics are collected.
 cpuidle/
 	- info on CPU_IDLE, CPU idle state management subsystem.
+cpusets.txt
+	- documents the cpusets feature; assign CPUs and Mem to a set of tasks.
 cputopology.txt
 	- documentation on how CPU topology info is exported via sysfs.
 cris/

trunk/Documentation/ABI/testing/sysfs-class-regulator

@@ -4,8 +4,8 @@ KernelVersion:	2.6.26
 Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
 		Some regulator directories will contain a field called
-		state. This reports the regulator enable control, for
-		regulators which can report that input value.
+		state. This reports the regulator enable status, for
+		regulators which can report that value.
 
 		This will be one of the following strings:
 
@@ -14,54 +14,16 @@ Description:
 		'unknown'
 
 		'enabled' means the regulator output is ON and is supplying
-		power to the system (assuming no error prevents it).
+		power to the system.
 
 		'disabled' means the regulator output is OFF and is not
-		supplying power to the system (unless some non-Linux
-		control has enabled it).
+		supplying power to the system..
 
 		'unknown' means software cannot determine the state, or
 		the reported state is invalid.
 
 		NOTE: this field can be used in conjunction with microvolts
-		or microamps to determine configured regulator output levels.
-
-
-What:		/sys/class/regulator/.../status
-Description:
-		Some regulator directories will contain a field called
-		"status". This reports the current regulator status, for
-		regulators which can report that output value.
-
-		This will be one of the following strings:
-
-			off
-			on
-			error
-			fast
-			normal
-			idle
-			standby
-
-		"off" means the regulator is not supplying power to the
-		system.
-
-		"on" means the regulator is supplying power to the system,
-		and the regulator can't report a detailed operation mode.
-
-		"error" indicates an out-of-regulation status such as being
-		disabled due to thermal shutdown, or voltage being unstable
-		because of problems with the input power supply.
-
-		"fast", "normal", "idle", and "standby" are all detailed
-		regulator operation modes (described elsewhere).  They
-		imply "on", but provide more detail.
-
-		Note that regulator status is a function of many inputs,
-		not limited to control inputs from Linux.  For example,
-		the actual load presented may trigger "error" status; or
-		a regulator may be enabled by another user, even though
-		Linux did not enable it.
+		and microamps to determine regulator output levels.
 
 
 What:		/sys/class/regulator/.../type
@@ -96,7 +58,7 @@ Description:
 		Some regulator directories will contain a field called
 		microvolts. This holds the regulator output voltage setting
 		measured in microvolts (i.e. E-6 Volts), for regulators
-		which can report the control input for voltage.
+		which can report that voltage.
 
 		NOTE: This value should not be used to determine the regulator
 		output voltage level as this value is the same regardless of
@@ -111,7 +73,7 @@ Description:
 		Some regulator directories will contain a field called
 		microamps. This holds the regulator output current limit
 		setting measured in microamps (i.e. E-6 Amps), for regulators
-		which can report the control input for a current limit.
+		which can report that current.
 
 		NOTE: This value should not be used to determine the regulator
 		output current level as this value is the same regardless of
@@ -125,7 +87,7 @@ Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
 		Some regulator directories will contain a field called
 		opmode. This holds the current regulator operating mode,
-		for regulators which can report that control input value.
+		for regulators which can report it.
 
 		The opmode value can be one of the following strings:
 
@@ -139,8 +101,7 @@ Description:
 
 		NOTE: This value should not be used to determine the regulator
 		output operating mode as this value is the same regardless of
-		whether the regulator is enabled or disabled.  A "status"
-		attribute may be available to determine the actual mode.
+		whether the regulator is enabled or disabled.
 
 
 What:		/sys/class/regulator/.../min_microvolts

trunk/Documentation/DocBook/.gitignore

@@ -4,7 +4,3 @@
 *.html
 *.9.gz
 *.9
-*.aux
-*.dvi
-*.log
-*.out

trunk/Documentation/RCU/listRCU.txt

@@ -118,7 +118,7 @@ Following are the RCU equivalents for these two functions:
 		list_for_each_entry(e, list, list) {
 			if (!audit_compare_rule(rule, &e->rule)) {
 				list_del_rcu(&e->list);
-				call_rcu(&e->rcu, audit_free_rule);
+				call_rcu(&e->rcu, audit_free_rule, e);
 				return 0;
 			}
 		}
@@ -206,7 +206,7 @@ RCU ("read-copy update") its name.  The RCU code is as follows:
 				ne->rule.action = newaction;
 				ne->rule.file_count = newfield_count;
 				list_replace_rcu(e, ne);
-				call_rcu(&e->rcu, audit_free_rule);
+				call_rcu(&e->rcu, audit_free_rule, e);
 				return 0;
 			}
 		}
@@ -283,7 +283,7 @@ flag under the spinlock as follows:
 				list_del_rcu(&e->list);
 				e->deleted = 1;
 				spin_unlock(&e->lock);
-				call_rcu(&e->rcu, audit_free_rule);
+				call_rcu(&e->rcu, audit_free_rule, e);
 				return 0;
 			}
 		}

trunk/Documentation/RCU/rcu.txt

@@ -81,7 +81,7 @@ o	I hear that RCU needs work in order to support realtime kernels?
 	This work is largely completed.  Realtime-friendly RCU can be
 	enabled via the CONFIG_PREEMPT_RCU kernel configuration parameter.
 	However, work is in progress for enabling priority boosting of
-	preempted RCU read-side critical sections.  This is needed if you
+	preempted RCU read-side critical sections.This is needed if you
 	have CPU-bound realtime threads.
 
 o	Where can I find more information on RCU?

trunk/Documentation/RCU/rculist_nulls.txt

@@ -21,7 +21,7 @@ if (obj) {
   /*
    * Because a writer could delete object, and a writer could
    * reuse these object before the RCU grace period, we
-   * must check key after getting the reference on object
+   * must check key after geting the reference on object
    */
   if (obj->key != key) { // not the object we expected
      put_ref(obj);
@@ -117,7 +117,7 @@ a race (some writer did a delete and/or a move of an object
 to another chain) checking the final 'nulls' value if
 the lookup met the end of chain. If final 'nulls' value
 is not the slot number, then we must restart the lookup at
-the beginning. If the object was moved to the same chain,
+the begining. If the object was moved to same chain,
 then the reader doesnt care : It might eventually
 scan the list again without harm.
 

trunk/Documentation/cgroups/cgroups.txt

@@ -56,7 +56,7 @@ hierarchy, and a set of subsystems; each subsystem has system-specific
 state attached to each cgroup in the hierarchy.  Each hierarchy has
 an instance of the cgroup virtual filesystem associated with it.
 
-At any one time there may be multiple active hierarchies of task
+At any one time there may be multiple active hierachies of task
 cgroups. Each hierarchy is a partition of all tasks in the system.
 
 User level code may create and destroy cgroups by name in an
@@ -124,10 +124,10 @@ following lines:
                                / \
                        Prof (15%) students (5%)
 
-Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go
+Browsers like firefox/lynx go into the WWW network class, while (k)nfsd go
 into NFS network class.
 
-At the same time Firefox/Lynx will share an appropriate CPU/Memory class
+At the same time firefox/lynx will share an appropriate CPU/Memory class
 depending on who launched it (prof/student).
 
 With the ability to classify tasks differently for different resources
@@ -325,31 +325,20 @@ and then start a subshell 'sh' in that cgroup:
 Creating, modifying, using the cgroups can be done through the cgroup
 virtual filesystem.
 
-To mount a cgroup hierarchy with all available subsystems, type:
+To mount a cgroup hierarchy will all available subsystems, type:
 # mount -t cgroup xxx /dev/cgroup
 
 The "xxx" is not interpreted by the cgroup code, but will appear in
 /proc/mounts so may be any useful identifying string that you like.
 
 To mount a cgroup hierarchy with just the cpuset and numtasks
 subsystems, type:
-# mount -t cgroup -o cpuset,memory hier1 /dev/cgroup
+# mount -t cgroup -o cpuset,numtasks hier1 /dev/cgroup
 
 To change the set of subsystems bound to a mounted hierarchy, just
 remount with different options:
-# mount -o remount,cpuset,ns hier1 /dev/cgroup
 
-Now memory is removed from the hierarchy and ns is added.
-
-Note this will add ns to the hierarchy but won't remove memory or
-cpuset, because the new options are appended to the old ones:
-# mount -o remount,ns /dev/cgroup
-
-To Specify a hierarchy's release_agent:
-# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
-  xxx /dev/cgroup
-
-Note that specifying 'release_agent' more than once will return failure.
+# mount -o remount,cpuset,ns  /dev/cgroup
 
 Note that changing the set of subsystems is currently only supported
 when the hierarchy consists of a single (root) cgroup. Supporting
@@ -360,11 +349,6 @@ Then under /dev/cgroup you can find a tree that corresponds to the
 tree of the cgroups in the system. For instance, /dev/cgroup
 is the cgroup that holds the whole system.
 
-If you want to change the value of release_agent:
-# echo "/sbin/new_release_agent" > /dev/cgroup/release_agent
-
-It can also be changed via remount.
-
 If you want to create a new cgroup under /dev/cgroup:
 # cd /dev/cgroup
 # mkdir my_cgroup
@@ -492,13 +476,11 @@ cgroup->parent is still valid. (Note - can also be called for a
 newly-created cgroup if an error occurs after this subsystem's
 create() method has been called for the new cgroup).
 
-int pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
+void pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
 
 Called before checking the reference count on each subsystem. This may
 be useful for subsystems which have some extra references even if
-there are not tasks in the cgroup. If pre_destroy() returns error code,
-rmdir() will fail with it. From this behavior, pre_destroy() can be
-called multiple times against a cgroup.
+there are not tasks in the cgroup.
 
 int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
 	       struct task_struct *task)
@@ -539,7 +521,7 @@ always handled well.
 void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
 (cgroup_mutex held by caller)
 
-Called at the end of cgroup_clone() to do any parameter
+Called at the end of cgroup_clone() to do any paramater
 initialization which might be required before a task could attach.  For
 example in cpusets, no task may attach before 'cpus' and 'mems' are set
 up.

trunk/Documentation/cgroups/cpusets.txt

@@ -131,7 +131,7 @@ Cpusets extends these two mechanisms as follows:
  - The hierarchy of cpusets can be mounted at /dev/cpuset, for
    browsing and manipulation from user space.
  - A cpuset may be marked exclusive, which ensures that no other
-   cpuset (except direct ancestors and descendants) may contain
+   cpuset (except direct ancestors and descendents) may contain
    any overlapping CPUs or Memory Nodes.
  - You can list all the tasks (by pid) attached to any cpuset.
 
@@ -226,7 +226,7 @@ nodes with memory--using the cpuset_track_online_nodes() hook.
 --------------------------------
 
 If a cpuset is cpu or mem exclusive, no other cpuset, other than
-a direct ancestor or descendant, may share any of the same CPUs or
+a direct ancestor or descendent, may share any of the same CPUs or
 Memory Nodes.
 
 A cpuset that is mem_exclusive *or* mem_hardwall is "hardwalled",
@@ -427,7 +427,7 @@ child cpusets have this flag enabled.
 When doing this, you don't usually want to leave any unpinned tasks in
 the top cpuset that might use non-trivial amounts of CPU, as such tasks
 may be artificially constrained to some subset of CPUs, depending on
-the particulars of this flag setting in descendant cpusets.  Even if
+the particulars of this flag setting in descendent cpusets.  Even if
 such a task could use spare CPU cycles in some other CPUs, the kernel
 scheduler might not consider the possibility of load balancing that
 task to that underused CPU.
@@ -531,9 +531,9 @@ be idle.
 
 Of course it takes some searching cost to find movable tasks and/or
 idle CPUs, the scheduler might not search all CPUs in the domain
-every time.  In fact, in some architectures, the searching ranges on
+everytime.  In fact, in some architectures, the searching ranges on
 events are limited in the same socket or node where the CPU locates,
-while the load balance on tick searches all.
+while the load balance on tick searchs all.
 
 For example, assume CPU Z is relatively far from CPU X.  Even if CPU Z
 is idle while CPU X and the siblings are busy, scheduler can't migrate
@@ -601,7 +601,7 @@ its new cpuset, then the task will continue to use whatever subset
 of MPOL_BIND nodes are still allowed in the new cpuset.  If the task
 was using MPOL_BIND and now none of its MPOL_BIND nodes are allowed
 in the new cpuset, then the task will be essentially treated as if it
-was MPOL_BIND bound to the new cpuset (even though its NUMA placement,
+was MPOL_BIND bound to the new cpuset (even though its numa placement,
 as queried by get_mempolicy(), doesn't change).  If a task is moved
 from one cpuset to another, then the kernel will adjust the tasks
 memory placement, as above, the next time that the kernel attempts

trunk/Documentation/cgroups/devices.txt

@@ -42,7 +42,7 @@ suffice, but we can decide the best way to adequately restrict
 movement as people get some experience with this.  We may just want
 to require CAP_SYS_ADMIN, which at least is a separate bit from
 CAP_MKNOD.  We may want to just refuse moving to a cgroup which
-isn't a descendant of the current one.  Or we may want to use
+isn't a descendent of the current one.  Or we may want to use
 CAP_MAC_ADMIN, since we really are trying to lock down root.
 
 CAP_SYS_ADMIN is needed to modify the whitelist or move another