---

yaml
---
r: 82925
b: refs/heads/master
c: e83aff5
h: refs/heads/master
i:
  82923: b6b441b
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 2c8296f8cf0ec40867965dddef3dfe92f73b38f4
+refs/heads/master: e83aff58bf1b7e6b355a0cfa206e9d3aebe5623f

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

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/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/SubmittingPatches

@@ -220,8 +220,20 @@ decreasing the likelihood of your MIME-attached change being accepted.
 Exception:  If your mailer is mangling patches then someone may ask
 you to re-send them using MIME.
 
-See Documentation/email-clients.txt for hints about configuring
-your e-mail client so that it sends your patches untouched.
+
+WARNING: Some mailers like Mozilla send your messages with
+---- message header ----
+Content-Type: text/plain; charset=us-ascii; format=flowed
+---- message header ----
+The problem is that "format=flowed" makes some of the mailers
+on receiving side to replace TABs with spaces and do similar
+changes. Thus the patches from you can look corrupted.
+
+To fix this just make your mozilla defaults/pref/mailnews.js file to look like:
+pref("mailnews.send_plaintext_flowed", false); // RFC 2646=======
+pref("mailnews.display.disable_format_flowed_support", true);
+
+
 
 8) E-mail size.
 

trunk/Documentation/arm/Sharp-LH/IOBarrier

@@ -32,7 +32,7 @@ BARRIER IO before the access to the SMC chip because the AEN latch
 only needs occurs after the SMC IO write cycle.  The routines that
 implement this work-around make an additional concession which is to
 disable interrupts during the IO sequence.  Other hardware devices
-(the LogicPD CPLD) have registers in the same physical memory
+(the LogicPD CPLD) have registers in the same the physical memory
 region as the SMC chip.  An interrupt might allow an access to one of
 those registers while SMC IO is being performed.
 

trunk/Documentation/debugging-modules.txt

@@ -16,7 +16,3 @@ echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
 echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe
 chmod a+x /tmp/modprobe
 echo /tmp/modprobe > /proc/sys/kernel/modprobe
-
-Note that the above applies only when the *kernel* is requesting
-that the module be loaded -- it won't have any effect if that module
-is being loaded explicitly using "modprobe" from userspace.

trunk/Documentation/driver-model/platform.txt

@@ -122,15 +122,15 @@ None the less, there are some APIs to support such legacy drivers.  Avoid
 using these calls except with such hotplug-deficient drivers.
 
 	struct platform_device *platform_device_alloc(
-			const char *name, int id);
+			char *name, unsigned id);
 
 You can use platform_device_alloc() to dynamically allocate a device, which
 you will then initialize with resources and platform_device_register().
 A better solution is usually:
 
 	struct platform_device *platform_device_register_simple(
-			const char *name, int id,
-			struct resource *res, unsigned int nres);
+			char *name, unsigned id,
+			struct resource *res, unsigned nres);
 
 You can use platform_device_register_simple() as a one-step call to allocate
 and register a device.

trunk/Documentation/filesystems/configfs/configfs.txt

@@ -377,7 +377,7 @@ more explicit to have a method whereby userspace sees this divergence.
 Rather than have a group where some items behave differently than
 others, configfs provides a method whereby one or many subgroups are
 automatically created inside the parent at its creation.  Thus,
-mkdir("parent") results in "parent", "parent/subgroup1", up through
+mkdir("parent) results in "parent", "parent/subgroup1", up through
 "parent/subgroupN".  Items of type 1 can now be created in
 "parent/subgroup1", and items of type N can be created in
 "parent/subgroupN".

trunk/Documentation/filesystems/porting

@@ -1,6 +1,6 @@
 Changes since 2.5.0:
 
----
+--- 
 [recommended]
 
 New helpers: sb_bread(), sb_getblk(), sb_find_get_block(), set_bh(),
@@ -10,7 +10,7 @@ Use them.
 
 (sb_find_get_block() replaces 2.4's get_hash_table())
 
----
+--- 
 [recommended]
 
 New methods: ->alloc_inode() and ->destroy_inode().
@@ -28,7 +28,7 @@ Declare
 
 Use FOO_I(inode) instead of &inode->u.foo_inode_i;
 
-Add foo_alloc_inode() and foo_destroy_inode() - the former should allocate
+Add foo_alloc_inode() and foo_destory_inode() - the former should allocate
 foo_inode_info and return the address of ->vfs_inode, the latter should free
 FOO_I(inode) (see in-tree filesystems for examples).
 

trunk/Documentation/filesystems/proc.txt

@@ -216,7 +216,6 @@ Table 1-3: Contents of the stat files (as of 2.6.22-rc3)
   priority      priority level
   nice          nice level
   num_threads   number of threads
-  it_real_value	(obsolete, always 0)
   start_time    time the process started after system boot
   vsize         virtual memory size
   rss           resident set memory size

trunk/Documentation/filesystems/ramfs-rootfs-initramfs.txt

@@ -118,7 +118,7 @@ All this differs from the old initrd in several ways:
     with the new root (cd /newmount; mount --move . /; chroot .), attach
     stdin/stdout/stderr to the new /dev/console, and exec the new init.
 
-    Since this is a remarkably persnickety process (and involves deleting
+    Since this is a remarkably persnickity process (and involves deleting
     commands before you can run them), the klibc package introduced a helper
     program (utils/run_init.c) to do all this for you.  Most other packages
     (such as busybox) have named this command "switch_root".

trunk/Documentation/filesystems/relay.txt

@@ -140,7 +140,7 @@ close()     decrements the channel buffer's refcount.  When the refcount
 In order for a user application to make use of relay files, the
 host filesystem must be mounted.  For example,
 
-	mount -t debugfs debugfs /sys/kernel/debug
+	mount -t debugfs debugfs /debug
 
 NOTE:   the host filesystem doesn't need to be mounted for kernel
 	clients to create or use channels - it only needs to be

trunk/Documentation/frv/booting.txt → trunk/Documentation/fujitsu/frv/booting.txt

@@ -177,5 +177,5 @@ separated by spaces:
   (*) vdc=...
 
       This option configures the MB93493 companion chip visual display
-      driver. Please see Documentation/frv/mb93493/vdc.txt for more
+      driver. Please see Documentation/fujitsu/mb93493/vdc.txt for more
       information.