---

yaml
---
r: 310440
b: refs/heads/master
c: 5307c95
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 0640113be25d283e0ff77a9f041e1242182387f0
+refs/heads/master: 5307c9556bc17e3cd26d4e94fc3b2565921834de

trunk/.mailmap

@@ -113,5 +113,3 @@ Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
 Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
 Takashi YOSHII <takashi.yoshii.zj@renesas.com>
 Yusuke Goda <goda.yusuke@renesas.com>
-Gustavo Padovan <gustavo@las.ic.unicamp.br>
-Gustavo Padovan <padovan@profusion.mobi>

trunk/Documentation/ABI/testing/sysfs-block-rssd

@@ -6,21 +6,13 @@ Description:    This is a read-only file. Dumps below driver information and
                 hardware registers.
                     - S ACTive
                     - Command Issue
+                    - Allocated
                     - Completed
                     - PORT IRQ STAT
                     - HOST IRQ STAT
-                    - Allocated
-                    - Commands in Q
 
 What:           /sys/block/rssd*/status
 Date:           April 2012
 KernelVersion:  3.4
 Contact:        Asai Thambi S P <asamymuthupa@micron.com>
-Description:    This is a read-only file. Indicates the status of the device.
-
-What:           /sys/block/rssd*/flags
-Date:           May 2012
-KernelVersion:  3.5
-Contact:        Asai Thambi S P <asamymuthupa@micron.com>
-Description:    This is a read-only file. Dumps the flags in port and driver
-                data structure
+Description:   This is a read-only file. Indicates the status of the device.

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

@@ -65,11 +65,11 @@ snap_*
 Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
 -------------------------------------------------------------
 
-snap_id
+id
 
 	The rados internal snapshot id assigned for this snapshot
 
-snap_size
+size
 
 	The size of the image when this snapshot was taken.
 

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

@@ -123,54 +123,3 @@ Description:
 		half page, or a quarter page).
 
 		In the case of ECC NOR, it is the ECC block size.
-
-What:		/sys/class/mtd/mtdX/ecc_strength
-Date:		April 2012
-KernelVersion:	3.4
-Contact:	linux-mtd@lists.infradead.org
-Description:
-		Maximum number of bit errors that the device is capable of
-		correcting within each region covering an ecc step.  This will
-		always be a non-negative integer.  Note that some devices will
-		have multiple ecc steps within each writesize region.
-
-		In the case of devices lacking any ECC capability, it is 0.
-
-What:		/sys/class/mtd/mtdX/bitflip_threshold
-Date:		April 2012
-KernelVersion:	3.4
-Contact:	linux-mtd@lists.infradead.org
-Description:
-		This allows the user to examine and adjust the criteria by which
-		mtd returns -EUCLEAN from mtd_read().  If the maximum number of
-		bit errors that were corrected on any single region comprising
-		an ecc step (as reported by the driver) equals or exceeds this
-		value, -EUCLEAN is returned.  Otherwise, absent an error, 0 is
-		returned.  Higher layers (e.g., UBI) use this return code as an
-		indication that an erase block may be degrading and should be
-		scrutinized as a candidate for being marked as bad.
-
-		The initial value may be specified by the flash device driver.
-		If not, then the default value is ecc_strength.
-
-		The introduction of this feature brings a subtle change to the
-		meaning of the -EUCLEAN return code.  Previously, it was
-		interpreted to mean simply "one or more bit errors were
-		corrected".  Its new interpretation can be phrased as "a
-		dangerously high number of bit errors were corrected on one or
-		more regions comprising an ecc step".  The precise definition of
-		"dangerously high" can be adjusted by the user with
-		bitflip_threshold.  Users are discouraged from doing this,
-		however, unless they know what they are doing and have intimate
-		knowledge of the properties of their device.  Broadly speaking,
-		bitflip_threshold should be low enough to detect genuine erase
-		block degradation, but high enough to avoid the consequences of
-		a persistent return value of -EUCLEAN on devices where sticky
-		bitflips occur.  Note that if bitflip_threshold exceeds
-		ecc_strength, -EUCLEAN is never returned by mtd_read().
-		Conversely, if bitflip_threshold is zero, -EUCLEAN is always
-		returned, absent a hard error.
-
-		This is generally applicable only to NAND flash devices with ECC
-		capability.  It is ignored on devices lacking ECC capability;
-		i.e., devices for which ecc_strength is zero.

trunk/Documentation/CodingStyle

@@ -671,9 +671,8 @@ ones already enabled by DEBUG.
 		Chapter 14: Allocating memory
 
 The kernel provides the following general purpose memory allocators:
-kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and
-vzalloc().  Please refer to the API documentation for further information
-about them.
+kmalloc(), kzalloc(), kcalloc(), vmalloc(), and vzalloc().  Please refer to
+the API documentation for further information about them.
 
 The preferred form for passing a size of a struct is the following:
 
@@ -687,17 +686,6 @@ Casting the return value which is a void pointer is redundant. The conversion
 from void pointer to any other pointer type is guaranteed by the C programming
 language.
 
-The preferred form for allocating an array is the following:
-
-	p = kmalloc_array(n, sizeof(...), ...);
-
-The preferred form for allocating a zeroed array is the following:
-
-	p = kcalloc(n, sizeof(...), ...);
-
-Both forms check for overflow on the allocation size n * sizeof(...),
-and return NULL if that occurred.
-
 
 		Chapter 15: The inline disease
 

trunk/Documentation/DocBook/mtdnand.tmpl

@@ -1119,6 +1119,8 @@ in this page</entry>
 		These constants are defined in nand.h. They are ored together to describe
 		the chip functionality.
      		<programlisting>
+/* Chip can not auto increment pages */
+#define NAND_NO_AUTOINCR	0x00000001
 /* Buswitdh is 16 bit */
 #define NAND_BUSWIDTH_16	0x00000002
 /* Device supports partial programming without padding */

trunk/Documentation/SubmittingPatches

@@ -150,8 +150,7 @@ be able to justify all violations that remain in your patch.
 
 Look through the MAINTAINERS file and the source code, and determine
 if your change applies to a specific subsystem of the kernel, with
-an assigned maintainer.  If so, e-mail that person.  The script
-scripts/get_maintainer.pl can be very useful at this step.
+an assigned maintainer.  If so, e-mail that person.
 
 If no maintainer is listed, or the maintainer does not respond, send
 your patch to the primary Linux kernel developer's mailing list,