---

yaml
---
r: 83331
b: refs/heads/master
c: 141e9d4
h: refs/heads/master
i:
  83329: 6de1174
  83327: e1a0a8d
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: c773633916c66f8362ca01983d97bd33e35b743f
+refs/heads/master: 141e9d4b5492499c4735d764b599c21e83dac154

trunk/.gitignore

@@ -17,7 +17,6 @@
 *.i
 *.lst
 *.symtypes
-*.order
 
 #
 # Top-level generic files

trunk/CREDITS

@@ -508,8 +508,12 @@ D: REINER SCT cyberJack pinpad/e-com USB chipcard reader driver
 S: Germany
 
 N: Adrian Bunk
+E: bunk@stusta.de
 P: 1024D/4F12B400  B29C E71E FE19 6755 5C8A  84D4 99FC EA98 4F12 B400
 D: misc kernel hacking and testing
+S: Grasmeierstrasse 11
+S: 80805 Muenchen
+S: Germany
 
 N: Ray Burr
 E: ryb@nightmare.com
@@ -1120,9 +1124,6 @@ S: 1150 Ringwood Court
 S: San Jose, California 95131
 S: USA
 
-N: Adam Fritzler
-E: mid@zigamorph.net
-
 N: Fernando Fuganti
 E: fuganti@conectiva.com.br
 E: fuganti@netbank.com.br
@@ -1352,14 +1353,6 @@ S: Gen Stedmanstraat 212
 S: 5623 HZ Eindhoven
 S: The Netherlands
 
-N: Oliver Hartkopp
-E: oliver.hartkopp@volkswagen.de
-W: http://www.volkswagen.de
-D: Controller Area Network (network layer core)
-S: Brieffach 1776
-S: 38436 Wolfsburg
-S: Germany
-
 N: Andrew Haylett
 E: ajh@primag.co.uk
 D: Selection mechanism
@@ -3313,14 +3306,6 @@ S: Universit=E9 de Rennes I
 S: F-35042 Rennes Cedex
 S: France
 
-N: Urs Thuermann
-E: urs.thuermann@volkswagen.de
-W: http://www.volkswagen.de
-D: Controller Area Network (network layer core)
-S: Brieffach 1776
-S: 38436 Wolfsburg
-S: Germany
-
 N: Jon Tombs
 E: jon@gte.esi.us.es
 W: http://www.esi.us.es/~jon

trunk/Documentation/00-INDEX

@@ -154,7 +154,7 @@ firmware_class/
 	- request_firmware() hotplug interface info.
 floppy.txt
 	- notes and driver options for the floppy disk driver.
-frv/
+fujitsu/
 	- Fujitsu FR-V Linux documentation.
 gpio.txt
 	- overview of GPIO (General Purpose Input/Output) access conventions.
@@ -364,6 +364,8 @@ sharedsubtree.txt
 	- a description of shared subtrees for namespaces.
 smart-config.txt
 	- description of the Smart Config makefile feature.
+smp.txt
+	- a few notes on symmetric multi-processing.
 sony-laptop.txt
 	- Sony Notebook Control Driver (SNC) Readme.
 sonypi.txt

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

@@ -52,36 +52,3 @@ Description:
 		facility is inherently dangerous, it is disabled by default
 		for all devices except hubs.  For more information, see
 		Documentation/usb/persist.txt.
-
-What:		/sys/bus/usb/device/.../power/connected_duration
-Date:		January 2008
-KernelVersion:	2.6.25
-Contact:	Sarah Sharp <sarah.a.sharp@intel.com>
-Description:
-		If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
-		is present.  When read, it returns the total time (in msec)
-		that the USB device has been connected to the machine.  This
-		file is read-only.
-Users:
-		PowerTOP <power@bughost.org>
-		http://www.lesswatts.org/projects/powertop/
-
-What:		/sys/bus/usb/device/.../power/active_duration
-Date:		January 2008
-KernelVersion:	2.6.25
-Contact:	Sarah Sharp <sarah.a.sharp@intel.com>
-Description:
-		If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
-		is present.  When read, it returns the total time (in msec)
-		that the USB device has been active, i.e. not in a suspended
-		state.  This file is read-only.
-
-		Tools can use this file and the connected_duration file to
-		compute the percentage of time that a device has been active.
-		For example,
-		echo $((100 * `cat active_duration` / `cat connected_duration`))
-		will give an integer percentage.  Note that this does not
-		account for counter wrap.
-Users:
-		PowerTOP <power@bughost.org>
-		http://www.lesswatts.org/projects/powertop/

trunk/Documentation/BUG-HUNTING

@@ -53,7 +53,7 @@ Finding it the old way
 
 [Sat Mar  2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)]
 
-This is how to track down a bug if you know nothing about kernel hacking.
+This is how to track down a bug if you know nothing about kernel hacking.  
 It's a brute force approach but it works pretty well.
 
 You need:
@@ -66,12 +66,12 @@ You will then do:
 
         . Rebuild a revision that you believe works, install, and verify that.
         . Do a binary search over the kernels to figure out which one
-          introduced the bug.  I.e., suppose 1.3.28 didn't have the bug, but
+          introduced the bug.  I.e., suppose 1.3.28 didn't have the bug, but 
           you know that 1.3.69 does.  Pick a kernel in the middle and build
           that, like 1.3.50.  Build & test; if it works, pick the mid point
           between .50 and .69, else the mid point between .28 and .50.
         . You'll narrow it down to the kernel that introduced the bug.  You
-          can probably do better than this but it gets tricky.
+          can probably do better than this but it gets tricky.  
 
         . Narrow it down to a subdirectory
 
@@ -81,27 +81,27 @@ You will then do:
             directories:
 
                 Copy the non-working directory next to the working directory
-                as "dir.63".
+                as "dir.63".  
                 One directory at time, try moving the working directory to
-                "dir.62" and mv dir.63 dir"time, try
+                "dir.62" and mv dir.63 dir"time, try 
 
                         mv dir dir.62
                         mv dir.63 dir
                         find dir -name '*.[oa]' -print | xargs rm -f
 
                 And then rebuild and retest.  Assuming that all related
-                changes were contained in the sub directory, this should
-                isolate the change to a directory.
+                changes were contained in the sub directory, this should 
+                isolate the change to a directory.  
 
                 Problems: changes in header files may have occurred; I've
-                found in my case that they were self explanatory - you may
+                found in my case that they were self explanatory - you may 
                 or may not want to give up when that happens.
 
         . Narrow it down to a file
 
           - You can apply the same technique to each file in the directory,
-            hoping that the changes in that file are self contained.
-
+            hoping that the changes in that file are self contained.  
+            
         . Narrow it down to a routine
 
           - You can take the old file and the new file and manually create
@@ -130,7 +130,7 @@ You will then do:
             that makes the difference.
 
 Finally, you take all the info that you have, kernel revisions, bug
-description, the extent to which you have narrowed it down, and pass
+description, the extent to which you have narrowed it down, and pass 
 that off to whomever you believe is the maintainer of that section.
 A post to linux.dev.kernel isn't such a bad idea if you've done some
 work to narrow it down.

trunk/Documentation/DocBook/Makefile

@@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
 	    procfs-guide.xml writing_usb_driver.xml \
 	    kernel-api.xml filesystems.xml lsm.xml usb.xml \
 	    gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
-	    genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml
+	    genericirq.xml s390-drivers.xml uio-howto.xml
 
 ###
 # The build process is as follows (targets):

trunk/Documentation/DocBook/kernel-api.tmpl

@@ -419,13 +419,7 @@ X!Edrivers/pnp/system.c
 
   <chapter id="blkdev">
      <title>Block Devices</title>
-!Eblock/blk-core.c
-!Eblock/blk-map.c
-!Iblock/blk-sysfs.c
-!Eblock/blk-settings.c
-!Eblock/blk-exec.c
-!Eblock/blk-barrier.c
-!Eblock/blk-tag.c
+!Eblock/ll_rw_blk.c
   </chapter>
 
   <chapter id="chrdev">

trunk/Documentation/DocBook/rapidio.tmpl

@@ -133,9 +133,9 @@
 !Idrivers/rapidio/rio-sysfs.c
      </sect1>
      <sect1><title>PPC32 support</title>
-!Iarch/powerpc/kernel/rio.c
-!Earch/powerpc/sysdev/fsl_rio.c
-!Iarch/powerpc/sysdev/fsl_rio.c
+!Iarch/ppc/kernel/rio.c
+!Earch/ppc/syslib/ppc85xx_rio.c
+!Iarch/ppc/syslib/ppc85xx_rio.c
      </sect1>
   </chapter>
 

trunk/Documentation/DocBook/s390-drivers.tmpl

@@ -59,7 +59,7 @@
    <title>Introduction</title>
   <para>
     This document describes the interfaces available for device drivers that
-    drive s390 based channel attached I/O devices. This includes interfaces for
+    drive s390 based channel attached devices. This includes interfaces for
     interaction with the hardware and interfaces for interacting with the
     common driver core. Those interfaces are provided by the s390 common I/O
     layer.
@@ -86,10 +86,9 @@
 	The ccw bus typically contains the majority of devices available to
 	a s390 system. Named after the channel command word (ccw), the basic
 	command structure used to address its devices, the ccw bus contains
-	so-called channel attached devices. They are addressed via I/O
-	subchannels, visible on the css bus. A device driver for
-	channel-attached devices, however, will never interact	with the
-	subchannel directly, but only via the I/O device on the ccw bus,
+	so-called channel attached devices. They are addressed via subchannels,
+	visible on the css bus. A device driver, however, will never interact
+	with the subchannel directly, but only via the device on the ccw bus,
 	the ccw device.
   </para>
     <sect1 id="channelIO">
@@ -147,15 +146,4 @@
    </sect1>
   </chapter>
 
-  <chapter id="genericinterfaces">
-   <title>Generic interfaces</title>
-  <para>
-	Some interfaces are available to other drivers that do not necessarily
-	have anything to do with the busses described above, but still are
-	indirectly using basic infrastructure in the common I/O layer.
-	One example is the support for adapter interrupts.
-  </para>
-!Edrivers/s390/cio/airq.c
-  </chapter>
-
 </book>