---

yaml
---
r: 189748
b: refs/heads/master
c: ae2d929
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: f16393776fc133d95fe3b3ba7118df579ed90af5
+refs/heads/master: ae2d9293d7cfba70f44f59cfedb44122828c73b8

trunk/Documentation/DocBook/tracepoint.tmpl

@@ -16,15 +16,6 @@
      </address>
     </affiliation>
    </author>
-   <author>
-    <firstname>William</firstname>
-    <surname>Cohen</surname>
-    <affiliation>
-     <address>
-      <email>wcohen@redhat.com</email>
-     </address>
-    </affiliation>
-   </author>
   </authorgroup>
 
   <legalnotice>
@@ -100,8 +91,4 @@
 !Iinclude/trace/events/signal.h
   </chapter>
 
-  <chapter id="block">
-   <title>Block IO</title>
-!Iinclude/trace/events/block.h
-  </chapter>
 </book>

trunk/Documentation/block/biodoc.txt

@@ -1162,8 +1162,8 @@ where a driver received a request ala this before:
 
 As mentioned, there is no virtual mapping of a bio. For DMA, this is
 not a problem as the driver probably never will need a virtual mapping.
-Instead it needs a bus mapping (dma_map_page for a single segment or
-use dma_map_sg for scatter gather) to be able to ship it to the driver. For
+Instead it needs a bus mapping (pci_map_page for a single segment or
+use blk_rq_map_sg for scatter gather) to be able to ship it to the driver. For
 PIO drivers (or drivers that need to revert to PIO transfer once in a
 while (IDE for example)), where the CPU is doing the actual data
 transfer a virtual mapping is needed. If the driver supports highmem I/O,

trunk/Documentation/connector/cn_test.c

@@ -25,7 +25,6 @@
 #include <linux/module.h>
 #include <linux/moduleparam.h>
 #include <linux/skbuff.h>
-#include <linux/slab.h>
 #include <linux/timer.h>
 
 #include <linux/connector.h>

trunk/Documentation/fb/efifb.txt → trunk/Documentation/fb/imacfb.txt

@@ -1,9 +1,9 @@
 
-What is efifb?
+What is imacfb?
 ===============
 
 This is a generic EFI platform driver for Intel based Apple computers.
-efifb is only for EFI booted Intel Macs.
+Imacfb is only for EFI booted Intel Macs.
 
 Supported Hardware
 ==================
@@ -16,16 +16,16 @@ MacMini
 How to use it?
 ==============
 
-efifb does not have any kind of autodetection of your machine.
+Imacfb does not have any kind of autodetection of your machine.
 You have to add the following kernel parameters in your elilo.conf:
 	Macbook :
-		video=efifb:macbook
+		video=imacfb:macbook
 	MacMini :
-		video=efifb:mini
+		video=imacfb:mini
 	Macbook Pro 15", iMac 17" :
-		video=efifb:i17
+		video=imacfb:i17
 	Macbook Pro 17", iMac 20" :
-		video=efifb:i20
+		video=imacfb:i20
 
 --
 Edgar Hucek <gimli@dark-green.com>

trunk/Documentation/filesystems/00-INDEX

@@ -16,8 +16,6 @@ befs.txt
 	- information about the BeOS filesystem for Linux.
 bfs.txt
 	- info for the SCO UnixWare Boot Filesystem (BFS).
-ceph.txt
-	- info for the Ceph Distributed File System
 cifs.txt
 	- description of the CIFS filesystem.
 coda.txt

trunk/Documentation/filesystems/9p.txt

@@ -37,15 +37,6 @@ For Plan 9 From User Space applications (http://swtch.com/plan9)
 
 	mount -t 9p `namespace`/acme /mnt/9 -o trans=unix,uname=$USER
 
-For server running on QEMU host with virtio transport:
-
-	mount -t 9p -o trans=virtio <mount_tag> /mnt/9
-
-where mount_tag is the tag associated by the server to each of the exported
-mount points. Each 9P export is seen by the client as a virtio device with an
-associated "mount_tag" property. Available mount tags can be
-seen by reading /sys/bus/virtio/drivers/9pnet_virtio/virtio<n>/mount_tag files.
-
 OPTIONS
 =======
 
@@ -56,7 +47,7 @@ OPTIONS
 			fd   	- used passed file descriptors for connection
                                 (see rfdno and wfdno)
 			virtio	- connect to the next virtio channel available
-				(from QEMU with trans_virtio module)
+				(from lguest or KVM with trans_virtio module)
 			rdma	- connect to a specified RDMA channel
 
   uname=name	user name to attempt mount as on the remote server.  The
@@ -94,12 +85,7 @@ OPTIONS
 
   port=n	port to connect to on the remote server
 
-  noextend	force legacy mode (no 9p2000.u or 9p2000.L semantics)
-
-  version=name	Select 9P protocol version. Valid options are:
-			9p2000          - Legacy mode (same as noextend)
-			9p2000.u        - Use 9P2000.u protocol
-			9p2000.L        - Use 9P2000.L protocol
+  noextend	force legacy mode (no 9p2000.u semantics)
 
   dfltuid	attempt to mount as a particular uid
 

trunk/Documentation/filesystems/ceph.txt

@@ -8,7 +8,7 @@ Basic features include:
 
  * POSIX semantics
  * Seamless scaling from 1 to many thousands of nodes
- * High availability and reliability.  No single point of failure.
+ * High availability and reliability.  No single points of failure.
  * N-way replication of data across storage nodes
  * Fast recovery from node failures
  * Automatic rebalancing of data on node addition/removal
@@ -94,7 +94,7 @@ Mount Options
 
   wsize=X
 	Specify the maximum write size in bytes.  By default there is no
-	maximum.  Ceph will normally size writes based on the file stripe
+	maximu.  Ceph will normally size writes based on the file stripe
 	size.
 
   rsize=X
@@ -115,7 +115,7 @@ Mount Options
 	number of entries in that directory.
 
   nocrc
-	Disable CRC32C calculation for data writes.  If set, the storage node
+	Disable CRC32C calculation for data writes.  If set, the OSD
 	must rely on TCP's error correction to detect data corruption
 	in the data payload.
 
@@ -133,8 +133,7 @@ For more information on Ceph, see the home page at
 	http://ceph.newdream.net/
 
 The Linux kernel client source tree is available at
-	git://ceph.newdream.net/git/ceph-client.git
-	git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git
+	git://ceph.newdream.net/linux-ceph-client.git
 
 and the source for the full system is at
-	git://ceph.newdream.net/git/ceph.git
+	git://ceph.newdream.net/ceph.git

trunk/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt

@@ -21,15 +21,6 @@ Required properties:
 - fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the
   threads.
 
-Optional properties:
-- fsl,firmware-phandle:
-    Usage: required only if there is no fsl,qe-firmware child node
-    Value type: <phandle>
-    Definition: Points to a firmware node (see "QE Firmware Node" below)
-        that contains the firmware that should be uploaded for this QE.
-        The compatible property for the firmware node should say,
-        "fsl,qe-firmware".
-
 Recommended properties
 - brg-frequency : the internal clock source frequency for baud-rate
   generators in Hz.
@@ -68,48 +59,3 @@ Example:
 		reg = <0 c000>;
 	};
      };
-
-* QE Firmware Node
-
-This node defines a firmware binary that is embedded in the device tree, for
-the purpose of passing the firmware from bootloader to the kernel, or from
-the hypervisor to the guest.
-
-The firmware node itself contains the firmware binary contents, a compatible
-property, and any firmware-specific properties.  The node should be placed
-inside a QE node that needs it.  Doing so eliminates the need for a
-fsl,firmware-phandle property.  Other QE nodes that need the same firmware
-should define an fsl,firmware-phandle property that points to the firmware node
-in the first QE node.
-
-The fsl,firmware property can be specified in the DTS (possibly using incbin)
-or can be inserted by the boot loader at boot time.
-
-Required properties:
-  - compatible
-      Usage: required
-      Value type: <string>
-      Definition: A standard property.  Specify a string that indicates what
-          kind of firmware it is.  For QE, this should be "fsl,qe-firmware".
-
-   - fsl,firmware
-      Usage: required
-      Value type: <prop-encoded-array>, encoded as an array of bytes
-      Definition: A standard property.  This property contains the firmware
-          binary "blob".
-
-Example:
-	qe1@e0080000 {
-		compatible = "fsl,qe";
-		qe_firmware:qe-firmware {
-			compatible = "fsl,qe-firmware";
-			fsl,firmware = [0x70 0xcd 0x00 0x00 0x01 0x46 0x45 ...];
-		};
-		...
-	};
-
-	qe2@e0090000 {
-		compatible = "fsl,qe";
-		fsl,firmware-phandle = <&qe_firmware>;
-		...
-	};

trunk/Documentation/sound/alsa/HD-Audio.txt

@@ -119,18 +119,10 @@ the codec slots 0 and 1 no matter what the hardware reports.
 
 Interrupt Handling
 ~~~~~~~~~~~~~~~~~~
-HD-audio driver uses MSI as default (if available) since 2.6.33
-kernel as MSI works better on some machines, and in general, it's
-better for performance.  However, Nvidia controllers showed bad
-regressions with MSI (especially in a combination with AMD chipset),
-thus we disabled MSI for them.
-
-There seem also still other devices that don't work with MSI.  If you
-see a regression wrt the sound quality (stuttering, etc) or a lock-up
-in the recent kernel, try to pass `enable_msi=0` option to disable
-MSI.  If it works, you can add the known bad device to the blacklist
-defined in hda_intel.c.  In such a case, please report and give the
-patch back to the upstream developer. 
+In rare but some cases, the interrupt isn't properly handled as
+default.  You would notice this by the DMA transfer error reported by
+ALSA PCM core, for example.  Using MSI might help in such a case.
+Pass `enable_msi=1` option for enabling MSI.
 
 
 HD-AUDIO CODEC