---

yaml
---
r: 221891
b: refs/heads/master
c: a2d771c
h: refs/heads/master
i:
  221889: 610b9a0
  221887: be68127
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: b5c551043617ecf84ad6bb888f96fdf4e4769d4c
+refs/heads/master: a2d771c036eb8c040683089ca04c36dfb93a0e60

trunk/Documentation/DocBook/kgdb.tmpl

@@ -710,18 +710,7 @@ Task Addr       Pid   Parent [*] cpu State Thread     Command
         <listitem><para>A simple shell</para></listitem>
         <listitem><para>The kdb core command set</para></listitem>
         <listitem><para>A registration API to register additional kdb shell commands.</para>
-	<itemizedlist>
-        <listitem><para>A good example of a self-contained kdb module
-        is the "ftdump" command for dumping the ftrace buffer.  See:
-        kernel/trace/trace_kdb.c</para></listitem>
-        <listitem><para>For an example of how to dynamically register
-        a new kdb command you can build the kdb_hello.ko kernel module
-        from samples/kdb/kdb_hello.c.  To build this example you can
-        set CONFIG_SAMPLES=y and CONFIG_SAMPLE_KDB=m in your kernel
-        config.  Later run "modprobe kdb_hello" and the next time you
-        enter the kdb shell, you can run the "hello"
-        command.</para></listitem>
-	</itemizedlist></listitem>
+        <para>A good example of a self-contained kdb module is the "ftdump" command for dumping the ftrace buffer.  See: kernel/trace/trace_kdb.c</para></listitem>
         <listitem><para>The implementation for kdb_printf() which
         emits messages directly to I/O drivers, bypassing the kernel
         log.</para></listitem>

trunk/Documentation/block/switching-sched.txt

@@ -16,7 +16,7 @@ you can do so by typing:
 As of the Linux 2.6.10 kernel, it is now possible to change the
 IO scheduler for a given block device on the fly (thus making it possible,
 for instance, to set the CFQ scheduler for the system default, but
-set a specific device to use the deadline or noop schedulers - which
+set a specific device to use the anticipatory or noop schedulers - which
 can improve that device's throughput).
 
 To set a specific scheduler, simply do this:
@@ -31,7 +31,7 @@ a "cat /sys/block/DEV/queue/scheduler" - the list of valid names
 will be displayed, with the currently selected scheduler in brackets:
 
 # cat /sys/block/hda/queue/scheduler
-noop deadline [cfq]
-# echo deadline > /sys/block/hda/queue/scheduler
+noop anticipatory deadline [cfq]
+# echo anticipatory > /sys/block/hda/queue/scheduler
 # cat /sys/block/hda/queue/scheduler
-noop [deadline] cfq
+noop [anticipatory] deadline cfq

trunk/Documentation/filesystems/Locking

@@ -322,13 +322,15 @@ fl_release_private:	yes	yes
 prototypes:
 	int (*fl_compare_owner)(struct file_lock *, struct file_lock *);
 	void (*fl_notify)(struct file_lock *);  /* unblock callback */
+	void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
 	void (*fl_release_private)(struct file_lock *);
 	void (*fl_break)(struct file_lock *); /* break_lease callback */
 
 locking rules:
 			BKL	may block
 fl_compare_owner:	yes	no
 fl_notify:		yes	no
+fl_copy_lock:		yes	no
 fl_release_private:	yes	yes
 fl_break:		yes	no
 

trunk/Documentation/filesystems/xfs-delayed-logging-design.txt

@@ -794,6 +794,17 @@ designed.
 
 Roadmap:
 
+2.6.37 Remove experimental tag from mount option
+	=> should be roughly 6 months after initial merge
+	=> enough time to:
+		=> gain confidence and fix problems reported by early
+		   adopters (a.k.a. guinea pigs)
+		=> address worst performance regressions and undesired
+		   behaviours
+		=> start tuning/optimising code for parallelism
+		=> start tuning/optimising algorithms consuming
+		   excessive CPU time
+
 2.6.39 Switch default mount option to use delayed logging
 	=> should be roughly 12 months after initial merge
 	=> enough time to shake out remaining problems before next round of

trunk/Documentation/i2c/busses/i2c-i801

@@ -15,14 +15,10 @@ Supported adapters:
   * Intel 82801I (ICH9)
   * Intel EP80579 (Tolapai)
   * Intel 82801JI (ICH10)
-  * Intel 5/3400 Series (PCH)
+  * Intel 3400/5 Series (PCH)
   * Intel Cougar Point (PCH)
-  * Intel Patsburg (PCH)
    Datasheets: Publicly available at the Intel website
 
-On Intel Patsburg and later chipsets, both the normal host SMBus controller
-and the additional 'Integrated Device Function' controllers are supported.
-
 Authors: 
 	Mark Studebaker <mdsxyz123@yahoo.com>
 	Jean Delvare <khali@linux-fr.org>

trunk/Documentation/kernel-parameters.txt

@@ -706,7 +706,7 @@ and is between 256 and 4096 characters. It is defined in the file
 			arch/x86/kernel/cpu/cpufreq/elanfreq.c.
 
 	elevator=	[IOSCHED]
-			Format: {"cfq" | "deadline" | "noop"}
+			Format: {"anticipatory" | "cfq" | "deadline" | "noop"}
 			See Documentation/block/as-iosched.txt and
 			Documentation/block/deadline-iosched.txt for details.
 

trunk/Documentation/leds-class.txt

@@ -60,18 +60,15 @@ Hardware accelerated blink of LEDs
 
 Some LEDs can be programmed to blink without any CPU interaction. To
 support this feature, a LED driver can optionally implement the
-blink_set() function (see <linux/leds.h>). To set an LED to blinking,
-however, it is better to use use the API function led_blink_set(),
-as it will check and implement software fallback if necessary.
-
-To turn off blinking again, use the API function led_brightness_set()
-as that will not just set the LED brightness but also stop any software
-timers that may have been required for blinking.
-
-The blink_set() function should choose a user friendly blinking value
-if it is called with *delay_on==0 && *delay_off==0 parameters. In this
-case the driver should give back the chosen value through delay_on and
-delay_off parameters to the leds subsystem.
+blink_set() function (see <linux/leds.h>). If implemented, triggers can
+attempt to use it before falling back to software timers. The blink_set()
+function should return 0 if the blink setting is supported, or -EINVAL
+otherwise, which means that LED blinking will be handled by software.
+
+The blink_set() function should choose a user friendly blinking
+value if it is called with *delay_on==0 && *delay_off==0 parameters. In
+this case the driver should give back the chosen value through delay_on
+and delay_off parameters to the leds subsystem.
 
 Setting the brightness to zero with brightness_set() callback function
 should completely turn off the LED and cancel the previously programmed

trunk/Documentation/rbtree.txt

@@ -21,8 +21,8 @@ three rotations, respectively, to balance the tree), with slightly slower
 To quote Linux Weekly News:
 
     There are a number of red-black trees in use in the kernel.
-    The deadline and CFQ I/O schedulers employ rbtrees to
-    track requests; the packet CD/DVD driver does the same.
+    The anticipatory, deadline, and CFQ I/O schedulers all employ
+    rbtrees to track requests; the packet CD/DVD driver does the same.
     The high-resolution timer code uses an rbtree to organize outstanding
     timer requests.  The ext3 filesystem tracks directory entries in a
     red-black tree.  Virtual memory areas (VMAs) are tracked with red-black

trunk/Documentation/scsi/ChangeLog.megaraid_sas

@@ -1,50 +1,3 @@
-1 Release Date    : Thur.  May 03, 2010 09:12:45 PST 2009 -
-			(emaild-id:megaraidlinux@lsi.com)
-			Bo Yang
-
-2 Current Version : 00.00.04.31-rc1
-3 Older Version   : 00.00.04.17.1-rc1
-
-1.	Add the Online Controller Reset (OCR) to the Driver.
-	OCR is the new feature for megaraid_sas driver which
-	will allow the fw to do the chip reset which will not
-	affact the OS behavious.
-
-	To add the OCR support, driver need to do:
-		a). reset the controller chips -- Xscale and Gen2 which
-		will change the function calls and add the reset function
-		related to this two chips.
-
-		b). during the reset, driver will store the pending cmds
-		which not returned by FW to driver's pending queue.  Driver
-		will re-issue those pending cmds again to FW after the OCR
-		finished.
-
-		c). In driver's timeout routine, driver will report to
-		OS as reset. Also driver's queue routine will block the
-		cmds until the OCR finished.
-
-		d). in Driver's ISR routine, if driver get the FW state as
-		state change, FW in Failure status and FW support online controller
-		reset (OCR), driver will start to do the controller reset.
-
-		e). In driver's IOCTL routine, the application cmds will wait for the
-		OCR to finish, then issue the cmds to FW.
-
-		f). Before driver kill adapter, driver will do last chance of
-		OCR to see if driver can bring back the FW.
-
-2.	Add the support update flag to the driver to tell LSI megaraid_sas
-	application which driver will support the device update.  So application
-	will not need to do the device update after application add/del the device
-	from the system.
-3.	In driver's timeout routine, driver will do three time reset if fw is in
-	failed state.  Driver will kill adapter if can't bring back FW after the
-	this three times reset.
-4.	Add the input parameter max_sectors to 1MB support to our GEN2 controller.
-	customer can use the input paramenter max_sectors to add 1MB support to GEN2
-	controller.
-
 1 Release Date    : Thur.  Oct 29, 2009 09:12:45 PST 2009 -
 			(emaild-id:megaraidlinux@lsi.com)
 			Bo Yang