Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

Conflicts:

	drivers/net/wireless/p54/p54common.c

.mailmap

@@ -80,6 +80,8 @@ Nguyen Anh Quynh <aquynh@gmail.com>
 Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
 Patrick Mochel <mochel@digitalimplant.org>
 Peter A Jonsson <pj@ludd.ltu.se>
+Peter Oruba <peter@oruba.de>
+Peter Oruba <peter.oruba@amd.com>
 Praveen BP <praveenbp@ti.com>
 Rajesh Shah <rajesh.shah@intel.com>
 Ralf Baechle <ralf@linux-mips.org>

Documentation/00-INDEX

@@ -172,7 +172,7 @@ i2c/
 	- directory with info about the I2C bus/protocol (2 wire, kHz speed).
 i2o/
 	- directory with info about the Linux I2O subsystem.
-i386/
+x86/i386/
 	- directory with info about Linux on Intel 32 bit architecture.
 ia64/
 	- directory with info about Linux on Intel 64 bit architecture.
@@ -382,7 +382,7 @@ w1/
 	- directory with documents regarding the 1-wire (w1) subsystem.
 watchdog/
 	- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
-x86_64/
+x86/x86_64/
 	- directory with info on Linux support for AMD x86-64 (Hammer) machines.
 zorro.txt
 	- info on writing drivers for Zorro bus devices found on Amigas.

Documentation/DocBook/Makefile

@@ -136,7 +136,7 @@ quiet_cmd_db2ps = PS      $@
 %.ps : %.xml
 	$(call cmd,db2ps)
 
-quiet_cmd_db2pdf = PDF      $@
+quiet_cmd_db2pdf = PDF     $@
       cmd_db2pdf = $(subst TYPE,pdf, $($(PDF_METHOD)template))
 %.pdf : %.xml
 	$(call cmd,db2pdf)
@@ -148,7 +148,7 @@ build_main_index = rm -rf $(main_idx) && \
 		   echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
 		   cat $(HTML) >> $(main_idx)
 
-quiet_cmd_db2html = HTML   $@
+quiet_cmd_db2html = HTML    $@
       cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
 		echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
         $(patsubst %.html,%,$(notdir $@))</a><p>' > $@

Documentation/DocBook/deviceiobook.tmpl

@@ -24,7 +24,7 @@
     <surname>Cox</surname>
     <affiliation>
      <address>
-      <email>alan@redhat.com</email>
+      <email>alan@lxorguk.ukuu.org.uk</email>
      </address>
     </affiliation>
    </author>

Documentation/DocBook/mcabook.tmpl

@@ -12,7 +12,7 @@
     <surname>Cox</surname>
     <affiliation>
      <address>
-      <email>alan@redhat.com</email>
+      <email>alan@lxorguk.ukuu.org.uk</email>
      </address>
     </affiliation>
    </author>

Documentation/DocBook/wanbook.tmpl

@@ -12,7 +12,7 @@
     <surname>Cox</surname>
     <affiliation>
      <address>
-      <email>alan@redhat.com</email>
+      <email>alan@lxorguk.ukuu.org.uk</email>
      </address>
     </affiliation>
    </author>

Documentation/DocBook/z8530book.tmpl

@@ -12,7 +12,7 @@
     <surname>Cox</surname>
     <affiliation>
      <address>
-      <email>alan@redhat.com</email>
+      <email>alan@lxorguk.ukuu.org.uk</email>
      </address>
     </affiliation>
    </author>

Documentation/ManagementStyle

@@ -17,7 +17,7 @@ companies.  If you sign purchase orders or you have any clue about the
 budget of your group, you're almost certainly not a kernel manager. 
 These suggestions may or may not apply to you. 
 
-First off, I'd suggest buying "Seven Habits of Highly Successful
+First off, I'd suggest buying "Seven Habits of Highly Effective
 People", and NOT read it.  Burn it, it's a great symbolic gesture. 
 
 (*) This document does so not so much by answering the question, but by

Documentation/accounting/.gitignore

@@ -0,0 +1 @@
+getdelays

Documentation/arm/empeg/README

@@ -1,13 +0,0 @@
-Empeg, Ltd's Empeg MP3 Car Audio Player
-
-The initial design is to go in your car, but you can use it at home, on a
-boat... almost anywhere. The principle is to store CD-quality music using
-MPEG technology onto a hard disk in the unit, and use the power of the
-embedded computer to serve up the music you want.
-
-For more details, see:
-
-	http://www.empeg.com
-
-
-

Documentation/arm/empeg/ir.txt

@@ -1,49 +0,0 @@
-Infra-red driver documentation.
-
-Mike Crowe <mac@empeg.com>
-(C) Empeg Ltd 1999
-
-Not a lot here yet :-)
-
-The Kenwood KCA-R6A remote control generates a sequence like the following:
-
-Go low for approx 16T (Around 9000us)
-Go high for approx 8T (Around 4000us)
-Go low for less than 2T (Around 750us)
-
-For each of the 32 bits
-  Go high for more than 2T (Around 1500us) == 1
-  Go high for less than T (Around 400us) == 0
-  Go low for less than 2T (Around 750us)
-
-Rather than repeat a signal when the button is held down certain buttons
-generate the following code to indicate repetition.
-
-Go low for approx 16T
-Go high for approx 4T
-Go low for less than 2T
-
-(By removing the <2T from the start of the sequence and placing at the end
- it can be considered a stop bit but I found it easier to deal with it at
- the start).
-
-The 32 bits are encoded as XxYy where x and y are the actual data values
-while X and Y are the logical inverses of the associated data values. Using 
-LSB first yields sensible codes for the numbers.
-
-All codes are of the form b9xx
-
-The numeric keys generate the code 0x where x is the number pressed.
-
-Tuner		1c
-Tape		1d
-CD		1e
-CD-MD-CH	1f
-Track-		0a
-Track+		0b
-Rewind		0c
-FF		0d
-DNPP		5e
-Play/Pause	0e
-Vol+		14
-Vol-		15

Documentation/arm/empeg/mkdevs

@@ -1,11 +0,0 @@
-#!/bin/sh
-mknod /dev/display c 244 0
-mknod /dev/ir c 242 0
-mknod /dev/usb0 c 243 0
-mknod /dev/audio c 245 4
-mknod /dev/dsp c 245 3
-mknod /dev/mixer c 245 0
-mknod /dev/empeg_state c 246 0
-mknod /dev/radio0 c 81 64
-ln -sf radio0 radio
-ln -sf usb0 usb

Documentation/auxdisplay/.gitignore

@@ -0,0 +1 @@
+cfag12864b-example

Documentation/connector/.gitignore

@@ -0,0 +1 @@
+ucon

Documentation/filesystems/Locking

@@ -161,8 +161,12 @@ prototypes:
 	int (*set_page_dirty)(struct page *page);
 	int (*readpages)(struct file *filp, struct address_space *mapping,
 			struct list_head *pages, unsigned nr_pages);
-	int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
+	int (*write_begin)(struct file *, struct address_space *mapping,
-	int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
+				loff_t pos, unsigned len, unsigned flags,
+				struct page **pagep, void **fsdata);
+	int (*write_end)(struct file *, struct address_space *mapping,
+				loff_t pos, unsigned len, unsigned copied,
+				struct page *page, void *fsdata);
 	sector_t (*bmap)(struct address_space *, sector_t);
 	int (*invalidatepage) (struct page *, unsigned long);
 	int (*releasepage) (struct page *, int);
@@ -180,8 +184,6 @@ sync_page:		no	maybe
 writepages:		no
 set_page_dirty		no	no
 readpages:		no
-prepare_write:		no	yes			yes
-commit_write:		no	yes			yes
 write_begin:		no	locks the page		yes
 write_end:		no	yes, unlocks		yes
 perform_write:		no	n/a			yes
@@ -191,7 +193,7 @@ releasepage:		no	yes
 direct_IO:		no
 launder_page:		no	yes
 
-	->prepare_write(), ->commit_write(), ->sync_page() and ->readpage()
+	->write_begin(), ->write_end(), ->sync_page() and ->readpage()
 may be called from the request handler (/dev/loop).
 
 	->readpage() unlocks the page, either synchronously or via I/O

Documentation/filesystems/vfs.txt

@@ -492,7 +492,7 @@ written-back to storage typically in whole pages, however the
 address_space has finer control of write sizes.
 
 The read process essentially only requires 'readpage'.  The write
-process is more complicated and uses prepare_write/commit_write or
+process is more complicated and uses write_begin/write_end or
 set_page_dirty to write data into the address_space, and writepage,
 sync_page, and writepages to writeback data to storage.
 
@@ -521,8 +521,6 @@ struct address_space_operations {
 	int (*set_page_dirty)(struct page *page);
 	int (*readpages)(struct file *filp, struct address_space *mapping,
 			struct list_head *pages, unsigned nr_pages);
-	int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
-	int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
 	int (*write_begin)(struct file *, struct address_space *mapping,
 				loff_t pos, unsigned len, unsigned flags,
 				struct page **pagep, void **fsdata);
@@ -598,37 +596,7 @@ struct address_space_operations {
 	readpages is only used for read-ahead, so read errors are
   	ignored.  If anything goes wrong, feel free to give up.
 
-  prepare_write: called by the generic write path in VM to set up a write
+  write_begin:
-  	request for a page.  This indicates to the address space that
-  	the given range of bytes is about to be written.  The
-  	address_space should check that the write will be able to
-  	complete, by allocating space if necessary and doing any other
-  	internal housekeeping.  If the write will update parts of
-  	any basic-blocks on storage, then those blocks should be
-  	pre-read (if they haven't been read already) so that the
-  	updated blocks can be written out properly.
-	The page will be locked.
-
-	Note: the page _must not_ be marked uptodate in this function
-	(or anywhere else) unless it actually is uptodate right now. As
-	soon as a page is marked uptodate, it is possible for a concurrent
-	read(2) to copy it to userspace.
-
-  commit_write: If prepare_write succeeds, new data will be copied
-        into the page and then commit_write will be called.  It will
-        typically update the size of the file (if appropriate) and
-        mark the inode as dirty, and do any other related housekeeping
-        operations.  It should avoid returning an error if possible -
-        errors should have been handled by prepare_write.
-
-  write_begin: This is intended as a replacement for prepare_write. The
-	key differences being that:
-		- it returns a locked page (in *pagep) rather than being
-		  given a pre locked page;
-		- it must be able to cope with short writes (where the
-		  length passed to write_begin is greater than the number
-		  of bytes copied into the page).
-
 	Called by the generic buffered write code to ask the filesystem to
 	prepare to write len bytes at the given offset in the file. The
 	address_space should check that the write will be able to complete,
@@ -640,6 +608,9 @@ struct address_space_operations {
         The filesystem must return the locked pagecache page for the specified
 	offset, in *pagep, for the caller to write into.
 
+	It must be able to cope with short writes (where the length passed to
+	write_begin is greater than the number of bytes copied into the page).
+
 	flags is a field for AOP_FLAG_xxx flags, described in
 	include/linux/fs.h.
 

Documentation/ftrace.txt

@@ -291,6 +291,9 @@ explains which is which.
   CPU#: The CPU which the process was running on.
 
   irqs-off: 'd' interrupts are disabled. '.' otherwise.
+	    Note: If the architecture does not support a way to
+		  read the irq flags variable, an 'X' will always
+		  be printed here.
 
   need-resched: 'N' task need_resched is set, '.' otherwise.
 

Documentation/i2c/busses/i2c-sis96x

@@ -42,7 +42,7 @@ I suspect that this driver could be made to work for the following SiS
 chipsets as well: 635, and 635T. If anyone owns a board with those chips
 AND is willing to risk crashing & burning an otherwise well-behaved kernel
 in the name of progress... please contact me at <mhoffman@lightlink.com> or
-via the project's mailing list: <i2c@lm-sensors.org>.  Please send bug
+via the linux-i2c mailing list: <linux-i2c@vger.kernel.org>.  Please send bug
 reports and/or success stories as well.
 
 

Documentation/ia64/.gitignore

@@ -0,0 +1 @@
+aliasing-test

Documentation/isdn/CREDITS

@@ -5,7 +5,7 @@ I want to thank all who contributed to this project and especially to:
 Thomas Bogendörfer (tsbogend@bigbug.franken.de)
   Tester, lots of bugfixes and hints.
 
-Alan Cox (alan@redhat.com)
+Alan Cox (alan@lxorguk.ukuu.org.uk)
   For help getting into standard-kernel.
 
 Henner Eisen (eis@baty.hanse.de)