---

yaml
---
r: 281959
b: refs/heads/master
c: f3f511e
h: refs/heads/master
i:
  281957: 60f5e32
  281955: 989fcd1
  281951: 7424661
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 979ecef5b89a8003902299566d9cdc08de34a3ee
+refs/heads/master: f3f511e1ce6f1a6f0a5bb8320e9f802e76f6b999

trunk/Documentation/ABI/testing/sysfs-bus-usb

@@ -119,31 +119,6 @@ Description:
 		Write a 1 to force the device to disconnect
 		(equivalent to unplugging a wired USB device).
 
-What:		/sys/bus/usb/drivers/.../new_id
-Date:		October 2011
-Contact:	linux-usb@vger.kernel.org
-Description:
-		Writing a device ID to this file will attempt to
-		dynamically add a new device ID to a USB device driver.
-		This may allow the driver to support more hardware than
-		was included in the driver's static device ID support
-		table at compile time. The format for the device ID is:
-		idVendor idProduct bInterfaceClass.
-		The vendor ID and device ID fields are required, the
-		interface class is optional.
-		Upon successfully adding an ID, the driver will probe
-		for the device and attempt to bind to it.  For example:
-		# echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
-
-What:		/sys/bus/usb-serial/drivers/.../new_id
-Date:		October 2011
-Contact:	linux-usb@vger.kernel.org
-Description:
-		For serial USB drivers, this attribute appears under the
-		extra bus folder "usb-serial" in sysfs; apart from that
-		difference, all descriptions from the entry
-		"/sys/bus/usb/drivers/.../new_id" apply.
-
 What:		/sys/bus/usb/drivers/.../remove_id
 Date:		November 2009
 Contact:	CHENG Renquan <rqcheng@smu.edu.sg>

trunk/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff

@@ -1,7 +1,7 @@
 What:		/sys/module/hid_logitech/drivers/hid:logitech/<dev>/range.
 Date:		July 2011
 KernelVersion:	3.2
-Contact:	Michal Malý <madcatxster@gmail.com>
+Contact:	Michal Mal� <madcatxster@gmail.com>
 Description:	Display minimum, maximum and current range of the steering
 		wheel. Writing a value within min and max boundaries sets the
 		range of the wheel.

trunk/Documentation/HOWTO

@@ -275,8 +275,8 @@ versions.
 If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
 kernel is the current stable kernel.
 
-2.6.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
-are released as needs dictate.  The normal release period is approximately
+2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are
+released as needs dictate.  The normal release period is approximately 
 two weeks, but it can be longer if there are no pressing problems.  A
 security-related problem, instead, can cause a release to happen almost
 instantly.

trunk/Documentation/cgroups/cgroups.txt

@@ -594,44 +594,53 @@ rmdir() will fail with it. From this behavior, pre_destroy() can be
 called multiple times against a cgroup.
 
 int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
-	       struct cgroup_taskset *tset)
+	       struct task_struct *task)
 (cgroup_mutex held by caller)
 
-Called prior to moving one or more tasks into a cgroup; if the
-subsystem returns an error, this will abort the attach operation.
-@tset contains the tasks to be attached and is guaranteed to have at
-least one task in it.
-
-If there are multiple tasks in the taskset, then:
-  - it's guaranteed that all are from the same thread group
-  - @tset contains all tasks from the thread group whether or not
-    they're switching cgroups
-  - the first task is the leader
-
-Each @tset entry also contains the task's old cgroup and tasks which
-aren't switching cgroup can be skipped easily using the
-cgroup_taskset_for_each() iterator. Note that this isn't called on a
-fork. If this method returns 0 (success) then this should remain valid
-while the caller holds cgroup_mutex and it is ensured that either
+Called prior to moving a task into a cgroup; if the subsystem
+returns an error, this will abort the attach operation.  If a NULL
+task is passed, then a successful result indicates that *any*
+unspecified task can be moved into the cgroup. Note that this isn't
+called on a fork. If this method returns 0 (success) then this should
+remain valid while the caller holds cgroup_mutex and it is ensured that either
 attach() or cancel_attach() will be called in future.
 
+int can_attach_task(struct cgroup *cgrp, struct task_struct *tsk);
+(cgroup_mutex held by caller)
+
+As can_attach, but for operations that must be run once per task to be
+attached (possibly many when using cgroup_attach_proc). Called after
+can_attach.
+
 void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
-		   struct cgroup_taskset *tset)
+	       struct task_struct *task, bool threadgroup)
 (cgroup_mutex held by caller)
 
 Called when a task attach operation has failed after can_attach() has succeeded.
 A subsystem whose can_attach() has some side-effects should provide this
 function, so that the subsystem can implement a rollback. If not, not necessary.
 This will be called only about subsystems whose can_attach() operation have
-succeeded. The parameters are identical to can_attach().
+succeeded.
+
+void pre_attach(struct cgroup *cgrp);
+(cgroup_mutex held by caller)
+
+For any non-per-thread attachment work that needs to happen before
+attach_task. Needed by cpuset.
 
 void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
-	    struct cgroup_taskset *tset)
+	    struct cgroup *old_cgrp, struct task_struct *task)
 (cgroup_mutex held by caller)
 
 Called after the task has been attached to the cgroup, to allow any
 post-attachment activity that requires memory allocations or blocking.
-The parameters are identical to can_attach().
+
+void attach_task(struct cgroup *cgrp, struct task_struct *tsk);
+(cgroup_mutex held by caller)
+
+As attach, but for operations that must be run once per task to be attached,
+like can_attach_task. Called before attach. Currently does not support any
+subsystem that might need the old_cgrp for every thread in the group.
 
 void fork(struct cgroup_subsy *ss, struct task_struct *task)
 

trunk/Documentation/cpu-freq/governors.txt

@@ -127,7 +127,7 @@ in the bash (as said, 1000 is default), do:
 echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \
     >ondemand/sampling_rate
 
-sampling_rate_min:
+show_sampling_rate_min:
 The sampling rate is limited by the HW transition latency:
 transition_latency * 100
 Or by kernel restrictions:
@@ -140,6 +140,8 @@ HZ=100:  min=200000us (200ms)
 The highest value of kernel and HW latency restrictions is shown and
 used as the minimum sampling rate.
 
+show_sampling_rate_max: THIS INTERFACE IS DEPRECATED, DON'T USE IT.
+
 up_threshold: defines what the average CPU usage between the samplings
 of 'sampling_rate' needs to be for the kernel to make a decision on
 whether it should increase the frequency.  For example when it is set

trunk/Documentation/development-process/5.Posting

@@ -271,10 +271,10 @@ copies should go to:
    the linux-kernel list.
 
  - If you are fixing a bug, think about whether the fix should go into the
-   next stable update.  If so, stable@vger.kernel.org should get a copy of
-   the patch.  Also add a "Cc: stable@vger.kernel.org" to the tags within
-   the patch itself; that will cause the stable team to get a notification
-   when your fix goes into the mainline.
+   next stable update.  If so, stable@kernel.org should get a copy of the
+   patch.  Also add a "Cc: stable@kernel.org" to the tags within the patch
+   itself; that will cause the stable team to get a notification when your
+   fix goes into the mainline.
 
 When selecting recipients for a patch, it is good to have an idea of who
 you think will eventually accept the patch and get it merged.  While it

trunk/Documentation/devices.txt

@@ -379,7 +379,7 @@ Your cooperation is appreciated.
 		162 = /dev/smbus	System Management Bus
 		163 = /dev/lik		Logitech Internet Keyboard
 		164 = /dev/ipmo		Intel Intelligent Platform Management
-		165 = /dev/vmmon	VMware virtual machine monitor
+		165 = /dev/vmmon	VMWare virtual machine monitor
 		166 = /dev/i2o/ctl	I2O configuration manager
 		167 = /dev/specialix_sxctl Specialix serial control
 		168 = /dev/tcldrv	Technology Concepts serial control

trunk/Documentation/devicetree/bindings/arm/fsl.txt

@@ -21,10 +21,6 @@ i.MX53 Smart Mobile Reference Design Board
 Required root node properties:
     - compatible = "fsl,imx53-smd", "fsl,imx53";
 
-i.MX6 Quad Armadillo2 Board
+i.MX6 Quad SABRE Automotive Board
 Required root node properties:
-    - compatible = "fsl,imx6q-arm2", "fsl,imx6q";
-
-i.MX6 Quad SABRE Lite Board
-Required root node properties:
-    - compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";
+    - compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";