---

yaml
---
r: 298390
b: refs/heads/master
c: 0b5f9c0
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: dd775ae2549217d3ae09363e3edb305d0fa19928
+refs/heads/master: 0b5f9c005def154f9c21f9be0223b65b50d54368

trunk/Documentation/ABI/stable/sysfs-driver-usb-usbtmc

@@ -55,7 +55,7 @@ What:		/sys/bus/usb/drivers/usbtmc/devices/*/auto_abort
 Date:		August 2008
 Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
-		This file determines if the transaction of the USB TMC
+		This file determines if the the transaction of the USB TMC
 		device is to be automatically aborted if there is any error.
 		For more details about this, please see the document,
 		"Universal Serial Bus Test and Measurement Class Specification

trunk/Documentation/ABI/testing/sysfs-firmware-acpi

@@ -1,23 +1,3 @@
-What:		/sys/firmware/acpi/bgrt/
-Date:		January 2012
-Contact:	Matthew Garrett <mjg@redhat.com>
-Description:
-		The BGRT is an ACPI 5.0 feature that allows the OS
-		to obtain a copy of the firmware boot splash and
-		some associated metadata. This is intended to be used
-		by boot splash applications in order to interact with
-		the firmware boot splash in order to avoid jarring
-		transitions.
-
-		image: The image bitmap. Currently a 32-bit BMP.
-		status: 1 if the image is valid, 0 if firmware invalidated it.
-		type: 0 indicates image is in BMP format.
-		version: The version of the BGRT. Currently 1.
-		xoffset: The number of pixels between the left of the screen
-			 and the left edge of the image.
-		yoffset: The number of pixels between the top of the screen
-			 and the top edge of the image.
-
 What:		/sys/firmware/acpi/interrupts/
 Date:		February 2008
 Contact:	Len Brown <lenb@kernel.org>

trunk/Documentation/CodingStyle

@@ -793,35 +793,6 @@ own custom mode, or may have some other magic method for making indentation
 work correctly.
 
 
-		Chapter 19:  Inline assembly
-
-In architecture-specific code, you may need to use inline assembly to interface
-with CPU or platform functionality.  Don't hesitate to do so when necessary.
-However, don't use inline assembly gratuitously when C can do the job.  You can
-and should poke hardware from C when possible.
-
-Consider writing simple helper functions that wrap common bits of inline
-assembly, rather than repeatedly writing them with slight variations.  Remember
-that inline assembly can use C parameters.
-
-Large, non-trivial assembly functions should go in .S files, with corresponding
-C prototypes defined in C header files.  The C prototypes for assembly
-functions should use "asmlinkage".
-
-You may need to mark your asm statement as volatile, to prevent GCC from
-removing it if GCC doesn't notice any side effects.  You don't always need to
-do so, though, and doing so unnecessarily can limit optimization.
-
-When writing a single inline assembly statement containing multiple
-instructions, put each instruction on a separate line in a separate quoted
-string, and end each string except the last with \n\t to properly indent the
-next instruction in the assembly output:
-
-	asm ("magic %reg1, #42\n\t"
-	     "more_magic %reg2, %reg3"
-	     : /* outputs */ : /* inputs */ : /* clobbers */);
-
-
 
 		Appendix I: References
 

trunk/Documentation/acpi/apei/einj.txt

@@ -53,14 +53,6 @@ directory apei/einj. The following files are provided.
   This file is used to set the second error parameter value. Effect of
   parameter depends on error_type specified.
 
-- notrigger
-  The EINJ mechanism is a two step process. First inject the error, then
-  perform some actions to trigger it. Setting "notrigger" to 1 skips the
-  trigger phase, which *may* allow the user to cause the error in some other
-  context by a simple access to the cpu, memory location, or device that is
-  the target of the error injection. Whether this actually works depends
-  on what operations the BIOS actually includes in the trigger phase.
-
 BIOS versions based in the ACPI 4.0 specification have limited options
 to control where the errors are injected.  Your BIOS may support an
 extension (enabled with the param_extension=1 module parameter, or

trunk/Documentation/aoe/aoe.txt

@@ -35,7 +35,7 @@ CREATING DEVICE NODES
     sh Documentation/aoe/mkshelf.sh /dev/etherd 0
 
   There is also an autoload script that shows how to edit
-  /etc/modprobe.d/aoe.conf to ensure that the aoe module is loaded when
+  /etc/modprobe.conf to ensure that the aoe module is loaded when
   necessary.
 
 USING DEVICE NODES

trunk/Documentation/aoe/autoload.sh

@@ -1,8 +1,8 @@
 #!/bin/sh
 # set aoe to autoload by installing the
-# aliases in /etc/modprobe.d/
+# aliases in /etc/modprobe.conf
 
-f=/etc/modprobe.d/aoe.conf
+f=/etc/modprobe.conf
 
 if test ! -r $f || test ! -w $f; then
 	echo "cannot configure $f for module autoloading" 1>&2

trunk/Documentation/blockdev/floppy.txt

@@ -49,7 +49,7 @@ you can put:
 
  options floppy omnibook messages
 
-in a configuration file in /etc/modprobe.d/.
+in /etc/modprobe.conf.
 
 
  The floppy driver related options are:

trunk/Documentation/cpuidle/sysfs.txt

@@ -36,7 +36,6 @@ drwxr-xr-x 2 root root 0 Feb  8 10:42 state3
 /sys/devices/system/cpu/cpu0/cpuidle/state0:
 total 0
 -r--r--r-- 1 root root 4096 Feb  8 10:42 desc
--rw-r--r-- 1 root root 4096 Feb  8 10:42 disable
 -r--r--r-- 1 root root 4096 Feb  8 10:42 latency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 name
 -r--r--r-- 1 root root 4096 Feb  8 10:42 power
@@ -46,7 +45,6 @@ total 0
 /sys/devices/system/cpu/cpu0/cpuidle/state1:
 total 0
 -r--r--r-- 1 root root 4096 Feb  8 10:42 desc
--rw-r--r-- 1 root root 4096 Feb  8 10:42 disable
 -r--r--r-- 1 root root 4096 Feb  8 10:42 latency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 name
 -r--r--r-- 1 root root 4096 Feb  8 10:42 power
@@ -56,7 +54,6 @@ total 0
 /sys/devices/system/cpu/cpu0/cpuidle/state2:
 total 0
 -r--r--r-- 1 root root 4096 Feb  8 10:42 desc
--rw-r--r-- 1 root root 4096 Feb  8 10:42 disable
 -r--r--r-- 1 root root 4096 Feb  8 10:42 latency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 name
 -r--r--r-- 1 root root 4096 Feb  8 10:42 power
@@ -66,7 +63,6 @@ total 0
 /sys/devices/system/cpu/cpu0/cpuidle/state3:
 total 0
 -r--r--r-- 1 root root 4096 Feb  8 10:42 desc
--rw-r--r-- 1 root root 4096 Feb  8 10:42 disable
 -r--r--r-- 1 root root 4096 Feb  8 10:42 latency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 name
 -r--r--r-- 1 root root 4096 Feb  8 10:42 power
@@ -76,7 +72,6 @@ total 0
 
 
 * desc : Small description about the idle state (string)
-* disable : Option to disable this idle state (bool)
 * latency : Latency to exit out of this idle state (in microseconds)
 * name : Name of the idle state (string)
 * power : Power consumed while in this idle state (in milliwatts)

trunk/Documentation/devicetree/bindings/mtd/arm-versatile.txt

@@ -4,5 +4,5 @@ Required properties:
 - compatible : must be "arm,versatile-flash";
 - bank-width : width in bytes of flash interface.
 
-The device tree may optionally contain sub-nodes describing partitions of the
-address space. See partition.txt for more detail.
+Optional properties:
+- Subnode partition map from mtd flash binding

trunk/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt

@@ -3,9 +3,6 @@
 Required properties:
 - compatible : "atmel,<model>", "atmel,<series>", "atmel,dataflash".
 
-The device tree may optionally contain sub-nodes describing partitions of the
-address space. See partition.txt for more detail.
-
 Example:
 
 flash@1 {

trunk/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt

@@ -19,10 +19,6 @@ Optional properties:
 	read registers (tR). Required if property "gpios" is not used
 	(R/B# pins not connected).
 
-Each flash chip described may optionally contain additional sub-nodes
-describing partitions of the address space. See partition.txt for more
-detail.
-
 Examples:
 
 upm@1,0 {

trunk/Documentation/devicetree/bindings/mtd/gpio-control-nand.txt

@@ -25,9 +25,6 @@ Optional properties:
   GPIO state and before and after command byte writes, this register will be
   read to ensure that the GPIO accesses have completed.
 
-The device tree may optionally contain sub-nodes describing partitions of the
-address space. See partition.txt for more detail.
-
 Examples:
 
 gpio-nand@1,0 {

trunk/Documentation/devicetree/bindings/mtd/mtd-physmap.txt

@@ -23,8 +23,27 @@ are defined:
  - vendor-id : Contains the flash chip's vendor id (1 byte).
  - device-id : Contains the flash chip's device id (1 byte).
 
-The device tree may optionally contain sub-nodes describing partitions of the
-address space. See partition.txt for more detail.
+In addition to the information on the mtd bank itself, the
+device tree may optionally contain additional information
+describing partitions of the address space.  This can be
+used on platforms which have strong conventions about which
+portions of a flash are used for what purposes, but which don't
+use an on-flash partition table such as RedBoot.
+
+Each partition is represented as a sub-node of the mtd device.
+Each node's name represents the name of the corresponding
+partition of the mtd device.
+
+Flash partitions
+ - reg : The partition's offset and size within the mtd bank.
+ - label : (optional) The label / name for this partition.
+   If omitted, the label is taken from the node name (excluding
+   the unit address).
+ - read-only : (optional) This parameter, if present, is a hint to
+   Linux that this partition should only be mounted
+   read-only.  This is usually used for flash partitions
+   containing early-boot firmware images or data which should not
+   be clobbered.
 
 Example: