---

yaml
---
r: 140344
b: refs/heads/master
c: 4f682fb
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: b983471794e568fd71fa767da77a62ba517c3e63
+refs/heads/master: 4f682fbb27deb308ca6a1e24ec9c2be41e6d1026

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

@@ -333,23 +333,12 @@ The "xxx" is not interpreted by the cgroup code, but will appear in
 
 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)

trunk/Documentation/cgroups/memcg_test.txt

@@ -1,5 +1,5 @@
 Memory Resource Controller(Memcg)  Implementation Memo.
-Last Updated: 2009/1/20
+Last Updated: 2009/1/19
 Base Kernel Version: based on 2.6.29-rc2.
 
 Because VM is getting complex (one of reasons is memcg...), memcg's behavior
@@ -360,21 +360,3 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
 	# kill malloc task.
 
 	Of course, tmpfs v.s. swapoff test should be tested, too.
-
- 9.8 OOM-Killer
-	Out-of-memory caused by memcg's limit will kill tasks under
-	the memcg. When hierarchy is used, a task under hierarchy
-	will be killed by the kernel.
-	In this case, panic_on_oom shouldn't be invoked and tasks
-	in other groups shouldn't be killed.
-
-	It's not difficult to cause OOM under memcg as following.
-	Case A) when you can swapoff
-	#swapoff -a
-	#echo 50M > /memory.limit_in_bytes
-	run 51M of malloc
-
-	Case B) when you use mem+swap limitation.
-	#echo 50M > memory.limit_in_bytes
-	#echo 50M > memory.memsw.limit_in_bytes
-	run 51M of malloc

trunk/Documentation/feature-removal-schedule.txt

@@ -255,16 +255,6 @@ Who:	Jan Engelhardt <jengelh@computergmbh.de>
 
 ---------------------------
 
-What:	GPIO autorequest on gpio_direction_{input,output}() in gpiolib
-When:	February 2010
-Why:	All callers should use explicit gpio_request()/gpio_free().
-	The autorequest mechanism in gpiolib was provided mostly as a
-	migration aid for legacy GPIO interfaces (for SOC based GPIOs).
-	Those users have now largely migrated.  Platforms implementing
-	the GPIO interfaces without using gpiolib will see no changes.
-Who:	David Brownell <dbrownell@users.sourceforge.net>
----------------------------
-
 What:	b43 support for firmware revision < 410
 When:	The schedule was July 2008, but it was decided that we are going to keep the
         code as long as there are no major maintanance headaches.