---

yaml
---
r: 235167
b: refs/heads/master
c: 0e00f7a
h: refs/heads/master
i:
  235165: 637edfb
  235163: 64bdec8
  235159: 7a99b73
  235151: 3f01e20
  235135: 3b2a09b
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: e7fd3b4669f5b835c8afce28425d9f698a558115
+refs/heads/master: 0e00f7aed6af21fc09b2a94d28bc34e449bd3a53

trunk/Documentation/ABI/testing/sysfs-devices-power

@@ -29,8 +29,9 @@ Description:
 		"disabled" to it.
 
 		For the devices that are not capable of generating system wakeup
-		events this file is not present.  In that case the device cannot
-		be enabled to wake up the system from sleep states.
+		events this file contains "\n".  In that cases the user space
+		cannot modify the contents of this file and the device cannot be
+		enabled to wake up the system.
 
 What:		/sys/devices/.../power/control
 Date:		January 2009
@@ -84,7 +85,7 @@ Description:
 		The /sys/devices/.../wakeup_count attribute contains the number
 		of signaled wakeup events associated with the device.  This
 		attribute is read-only.  If the device is not enabled to wake up
-		the system from sleep states, this attribute is not present.
+		the system from sleep states, this attribute is empty.
 
 What:		/sys/devices/.../power/wakeup_active_count
 Date:		September 2010
@@ -94,7 +95,7 @@ Description:
 		number of times the processing of wakeup events associated with
 		the device was completed (at the kernel level).  This attribute
 		is read-only.  If the device is not enabled to wake up the
-		system from sleep states, this attribute is not present.
+		system from sleep states, this attribute is empty.
 
 What:		/sys/devices/.../power/wakeup_hit_count
 Date:		September 2010
@@ -104,8 +105,7 @@ Description:
 		number of times the processing of a wakeup event associated with
 		the device might prevent the system from entering a sleep state.
 		This attribute is read-only.  If the device is not enabled to
-		wake up the system from sleep states, this attribute is not
-		present.
+		wake up the system from sleep states, this attribute is empty.
 
 What:		/sys/devices/.../power/wakeup_active
 Date:		September 2010
@@ -115,7 +115,7 @@ Description:
 		or 0, depending on whether or not a wakeup event associated with
 		the device is being processed (1).  This attribute is read-only.
 		If the device is not enabled to wake up the system from sleep
-		states, this attribute is not present.
+		states, this attribute is empty.
 
 What:		/sys/devices/.../power/wakeup_total_time_ms
 Date:		September 2010
@@ -125,7 +125,7 @@ Description:
 		the total time of processing wakeup events associated with the
 		device, in milliseconds.  This attribute is read-only.  If the
 		device is not enabled to wake up the system from sleep states,
-		this attribute is not present.
+		this attribute is empty.
 
 What:		/sys/devices/.../power/wakeup_max_time_ms
 Date:		September 2010
@@ -135,7 +135,7 @@ Description:
 		the maximum time of processing a single wakeup event associated
 		with the device, in milliseconds.  This attribute is read-only.
 		If the device is not enabled to wake up the system from sleep
-		states, this attribute is not present.
+		states, this attribute is empty.
 
 What:		/sys/devices/.../power/wakeup_last_time_ms
 Date:		September 2010
@@ -146,7 +146,7 @@ Description:
 		signaling the last wakeup event associated with the device, in
 		milliseconds.  This attribute is read-only.  If the device is
 		not enabled to wake up the system from sleep states, this
-		attribute is not present.
+		attribute is empty.
 
 What:		/sys/devices/.../power/autosuspend_delay_ms
 Date:		September 2010

trunk/Documentation/RCU/whatisRCU.txt

@@ -849,37 +849,6 @@ All:  lockdep-checked RCU-protected pointer access
 See the comment headers in the source code (or the docbook generated
 from them) for more information.
 
-However, given that there are no fewer than four families of RCU APIs
-in the Linux kernel, how do you choose which one to use?  The following
-list can be helpful:
-
-a.	Will readers need to block?  If so, you need SRCU.
-
-b.	What about the -rt patchset?  If readers would need to block
-	in an non-rt kernel, you need SRCU.  If readers would block
-	in a -rt kernel, but not in a non-rt kernel, SRCU is not
-	necessary.
-
-c.	Do you need to treat NMI handlers, hardirq handlers,
-	and code segments with preemption disabled (whether
-	via preempt_disable(), local_irq_save(), local_bh_disable(),
-	or some other mechanism) as if they were explicit RCU readers?
-	If so, you need RCU-sched.
-
-d.	Do you need RCU grace periods to complete even in the face
-	of softirq monopolization of one or more of the CPUs?  For
-	example, is your code subject to network-based denial-of-service
-	attacks?  If so, you need RCU-bh.
-
-e.	Is your workload too update-intensive for normal use of
-	RCU, but inappropriate for other synchronization mechanisms?
-	If so, consider SLAB_DESTROY_BY_RCU.  But please be careful!
-
-f.	Otherwise, use RCU.
-
-Of course, this all assumes that you have determined that RCU is in fact
-the right tool for your job.
-
 
 8.  ANSWERS TO QUICK QUIZZES
 

trunk/Documentation/devicetree/booting-without-of.txt

@@ -13,7 +13,6 @@ Table of Contents
 
   I - Introduction
     1) Entry point for arch/powerpc
-    2) Entry point for arch/x86
 
   II - The DT block format
     1) Header
@@ -226,25 +225,6 @@ it with special cases.
   cannot support both configurations with Book E and configurations
   with classic Powerpc architectures.
 
-2) Entry point for arch/x86
--------------------------------
-
-  There is one single 32bit entry point to the kernel at code32_start,
-  the decompressor (the real mode entry point goes to the same  32bit
-  entry point once it switched into protected mode). That entry point
-  supports one calling convention which is documented in
-  Documentation/x86/boot.txt
-  The physical pointer to the device-tree block (defined in chapter II)
-  is passed via setup_data which requires at least boot protocol 2.09.
-  The type filed is defined as
-
-  #define SETUP_DTB                      2
-
-  This device-tree is used as an extension to the "boot page". As such it
-  does not parse / consider data which is already covered by the boot
-  page. This includes memory size, reserved ranges, command line arguments
-  or initrd address. It simply holds information which can not be retrieved
-  otherwise like interrupt routing or a list of devices behind an I2C bus.
 
 II - The DT block format
 ========================

trunk/Documentation/kernel-parameters.txt

@@ -2444,10 +2444,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			<deci-seconds>: poll all this frequency
 			0: no polling (default)
 
-	threadirqs	[KNL]
-			Force threading of all interrupt handlers except those
-			marked explicitely IRQF_NO_THREAD.
-
 	topology=	[S390]
 			Format: {off | on}
 			Specify if the kernel should make use of the cpu

trunk/Documentation/keys-request-key.txt

@@ -127,15 +127,14 @@ This is because process A's keyrings can't simply be attached to
 of them, and (b) it requires the same UID/GID/Groups all the way through.
 
 
-====================================
-NEGATIVE INSTANTIATION AND REJECTION
-====================================
+======================
+NEGATIVE INSTANTIATION
+======================
 
 Rather than instantiating a key, it is possible for the possessor of an
 authorisation key to negatively instantiate a key that's under construction.
 This is a short duration placeholder that causes any attempt at re-requesting
-the key whilst it exists to fail with error ENOKEY if negated or the specified
-error if rejected.
+the key whilst it exists to fail with error ENOKEY.
 
 This is provided to prevent excessive repeated spawning of /sbin/request-key
 processes for a key that will never be obtainable.