---

yaml
---
r: 24527
b: refs/heads/master
c: d4965b3
h: refs/heads/master
i:
  24525: bd66509
  24523: d77cff7
  24519: 4dcc328
  24511: 1040a95
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: aee85fe8e8143d3f54d9e6d3c6cdd40ead563267
+refs/heads/master: d4965b3e2ff94d0c7b7e6e7e9794b54950a2f4b9

trunk/CREDITS

@@ -1127,8 +1127,10 @@ S: Carnegie, Pennsylvania 15106-4304
 S: USA
 
 N: Philip Gladstone
-E: philip@raptor.com
+E: philip@gladstonefamily.net
 D: Kernel / timekeeping stuff
+S: Carlisle, MA 01741
+S: USA
 
 N: Jan-Benedict Glaw
 E: jbglaw@lug-owl.de
@@ -3741,10 +3743,11 @@ D: Mylex DAC960 PCI RAID driver
 D: Miscellaneous kernel fixes
 
 N: Alessandro Zummo
-E: azummo@ita.flashnet.it
-W: http://freepage.logicom.it/azummo/
+E: a.zummo@towertech.it
 D: CMI8330 support is sb_card.c
 D: ISAPnP fixes in sb_card.c
+D: ZyXEL omni.net lcd plus driver
+D: RTC subsystem
 S: Italy
 
 N: Marc Zyngier

trunk/Documentation/DMA-mapping.txt

@@ -199,6 +199,8 @@ address during PCI bus mastering you might do something like:
 		       "mydev: 24-bit DMA addressing not available.\n");
 		goto ignore_this_device;
 	}
+[Better use DMA_24BIT_MASK instead of 0x00ffffff.
+See linux/include/dma-mapping.h for reference.]
 
 When pci_set_dma_mask() is successful, and returns zero, the PCI layer
 saves away this mask you have provided.  The PCI layer will use this

trunk/Documentation/RCU/whatisRCU.txt

@@ -605,7 +605,7 @@ are the same as those shown in the preceding section, so they are omitted.
 	{
 		int cpu;
 
-		for_each_cpu(cpu)
+		for_each_possible_cpu(cpu)
 			run_on(cpu);
 	}
 

trunk/Documentation/block/biodoc.txt

@@ -132,8 +132,18 @@ Some new queue property settings:
 		limit. No highmem default.
 
 	blk_queue_max_sectors(q, max_sectors)
-		Maximum size request you can handle in units of 512 byte
-		sectors. 255 default.
+		Sets two variables that limit the size of the request.
+
+		- The request queue's max_sectors, which is a soft size in
+		in units of 512 byte sectors, and could be dynamically varied
+		by the core kernel.
+
+		- The request queue's max_hw_sectors, which is a hard limit
+		and reflects the maximum size request a driver can handle
+		in units of 512 byte sectors.
+
+		The default for both max_sectors and max_hw_sectors is
+		255. The upper limit of max_sectors is 1024.
 
 	blk_queue_max_phys_segments(q, max_segments)
 		Maximum physical segments you can handle in a request. 128

trunk/Documentation/cachetlb.txt

@@ -362,6 +362,27 @@ maps this page at its virtual address.
 	likely that you will need to flush the instruction cache
 	for copy_to_user_page().
 
+  void flush_anon_page(struct page *page, unsigned long vmaddr)
+  	When the kernel needs to access the contents of an anonymous
+	page, it calls this function (currently only
+	get_user_pages()).  Note: flush_dcache_page() deliberately
+	doesn't work for an anonymous page.  The default
+	implementation is a nop (and should remain so for all coherent
+	architectures).  For incoherent architectures, it should flush
+	the cache of the page at vmaddr in the current user process.
+
+  void flush_kernel_dcache_page(struct page *page)
+	When the kernel needs to modify a user page is has obtained
+	with kmap, it calls this function after all modifications are
+	complete (but before kunmapping it) to bring the underlying
+	page up to date.  It is assumed here that the user has no
+	incoherent cached copies (i.e. the original page was obtained
+	from a mechanism like get_user_pages()).  The default
+	implementation is a nop and should remain so on all coherent
+	architectures.  On incoherent architectures, this should flush
+	the kernel cache for page (using page_address(page)).
+
+
   void flush_icache_range(unsigned long start, unsigned long end)
   	When the kernel stores into addresses that it will execute
 	out of (eg when loading modules), this function is called.

trunk/Documentation/cpu-hotplug.txt

@@ -97,13 +97,13 @@ at which time hotplug is disabled.
 
 You really dont need to manipulate any of the system cpu maps. They should
 be read-only for most use. When setting up per-cpu resources almost always use
-cpu_possible_map/for_each_cpu() to iterate.
+cpu_possible_map/for_each_possible_cpu() to iterate.
 
 Never use anything other than cpumask_t to represent bitmap of CPUs.
 
 #include <linux/cpumask.h>
 
-for_each_cpu              - Iterate over cpu_possible_map
+for_each_possible_cpu     - Iterate over cpu_possible_map
 for_each_online_cpu       - Iterate over cpu_online_map
 for_each_present_cpu      - Iterate over cpu_present_map
 for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.

trunk/Documentation/cputopology.txt

@@ -1,5 +1,5 @@
 
-Export cpu topology info by sysfs. Items (attributes) are similar
+Export cpu topology info via sysfs. Items (attributes) are similar
 to /proc/cpuinfo.
 
 1) /sys/devices/system/cpu/cpuX/topology/physical_package_id:
@@ -12,7 +12,7 @@ represent the thread siblings to cpu X in the same core;
 represent the thread siblings to cpu X in the same physical package;
 
 To implement it in an architecture-neutral way, a new source file,
-driver/base/topology.c, is to export the 5 attributes.
+drivers/base/topology.c, is to export the 4 attributes.
 
 If one architecture wants to support this feature, it just needs to
 implement 4 defines, typically in file include/asm-XXX/topology.h.

trunk/Documentation/drivers/edac/edac.txt

@@ -21,21 +21,21 @@ within the computer system. In the initial release, memory Correctable Errors
 
 Detecting CE events, then harvesting those events and reporting them,
 CAN be a predictor of future UE events.  With CE events, the system can
-continue to operate, but with less safety. Preventive maintainence and
+continue to operate, but with less safety. Preventive maintenance and
 proactive part replacement of memory DIMMs exhibiting CEs can reduce
 the likelihood of the dreaded UE events and system 'panics'.
 
 
 In addition, PCI Bus Parity and SERR Errors are scanned for on PCI devices
 in order to determine if errors are occurring on data transfers.
 The presence of PCI Parity errors must be examined with a grain of salt.
-There are several addin adapters that do NOT follow the PCI specification
+There are several add-in adapters that do NOT follow the PCI specification
 with regards to Parity generation and reporting. The specification says
 the vendor should tie the parity status bits to 0 if they do not intend
 to generate parity.  Some vendors do not do this, and thus the parity bit
 can "float" giving false positives.
 
-The PCI Parity EDAC device has the ability to "skip" known flakey
+The PCI Parity EDAC device has the ability to "skip" known flaky
 cards during the parity scan. These are set by the parity "blacklist"
 interface in the sysfs for PCI Parity. (See the PCI section in the sysfs
 section below.) There is also a parity "whitelist" which is used as
@@ -101,7 +101,7 @@ Memory Controller (mc) Model
 
 First a background on the memory controller's model abstracted in EDAC.
 Each mc device controls a set of DIMM memory modules. These modules are
-layed out in a Chip-Select Row (csrowX) and Channel table (chX). There can
+laid out in a Chip-Select Row (csrowX) and Channel table (chX). There can
 be multiple csrows and two channels.
 
 Memory controllers allow for several csrows, with 8 csrows being a typical value.
@@ -131,7 +131,7 @@ for memory DIMMs:
 	DIMM_B1
 
 Labels for these slots are usually silk screened on the motherboard. Slots
-labeled 'A' are channel 0 in this example. Slots labled 'B'
+labeled 'A' are channel 0 in this example. Slots labeled 'B'
 are channel 1. Notice that there are two csrows possible on a
 physical DIMM. These csrows are allocated their csrow assignment
 based on the slot into which the memory DIMM is placed. Thus, when 1 DIMM
@@ -140,7 +140,7 @@ is placed in each Channel, the csrows cross both DIMMs.
 Memory DIMMs come single or dual "ranked". A rank is a populated csrow.
 Thus, 2 single ranked DIMMs, placed in slots DIMM_A0 and DIMM_B0 above
 will have 1 csrow, csrow0. csrow1 will be empty. On the other hand,
-when 2 dual ranked DIMMs are similiaryly placed, then both csrow0 and
+when 2 dual ranked DIMMs are similarly placed, then both csrow0 and
 csrow1 will be populated. The pattern repeats itself for csrow2 and
 csrow3.
 
@@ -246,7 +246,7 @@ Module Version read-only attribute file:
 
 	'mc_version'
 
-	The EDAC CORE modules's version and compile date are shown here to
+	The EDAC CORE module's version and compile date are shown here to
 	indicate what EDAC is running.
 
 
@@ -423,7 +423,7 @@ Total memory managed by this csrow attribute file:
 	'size_mb'
 
 	This attribute file displays, in count of megabytes, of memory
-	that this csrow contatins.
+	that this csrow contains.
 
 
 Memory Type attribute file:
@@ -557,7 +557,7 @@ On Header Type 00 devices the primary status is looked at
 for any parity error regardless of whether Parity is enabled on the
 device.  (The spec indicates parity is generated in some cases).
 On Header Type 01 bridges, the secondary status register is also
-looked at to see if parity ocurred on the bus on the other side of
+looked at to see if parity occurred on the bus on the other side of
 the bridge.
 
 
@@ -588,7 +588,7 @@ Panic on PCI PARITY Error:
 	'panic_on_pci_parity'
 
 
-	This control files enables or disables panic'ing when a parity
+	This control files enables or disables panicking when a parity
 	error has been detected.
 
 
@@ -616,12 +616,12 @@ PCI Device Whitelist:
 
 	This control file allows for an explicit list of PCI devices to be
 	scanned for parity errors. Only devices found on this list will
-	be examined.  The list is a line of hexadecimel VENDOR and DEVICE
+	be examined.  The list is a line of hexadecimal VENDOR and DEVICE
 	ID tuples:
 
 	1022:7450,1434:16a6
 
-	One or more can be inserted, seperated by a comma.
+	One or more can be inserted, separated by a comma.
 
 	To write the above list doing the following as one command line:
 
@@ -639,26 +639,26 @@ PCI Device Blacklist:
 
 	This control file allows for a list of PCI devices to be
 	skipped for scanning.
-	The list is a line of hexadecimel VENDOR and DEVICE ID tuples:
+	The list is a line of hexadecimal VENDOR and DEVICE ID tuples:
 
 	1022:7450,1434:16a6
 
-	One or more can be inserted, seperated by a comma.
+	One or more can be inserted, separated by a comma.
 
 	To write the above list doing the following as one command line:
 
 	echo "1022:7450,1434:16a6"
 		> /sys/devices/system/edac/pci/pci_parity_blacklist
 
 
-	To display what the whitelist current contatins,
+	To display what the whitelist currently contains,
 	simply 'cat' the same file.
 
 =======================================================================
 
 PCI Vendor and Devices IDs can be obtained with the lspci command. Using
 the -n option lspci will display the vendor and device IDs. The system
-adminstrator will have to determine which devices should be scanned or
+administrator will have to determine which devices should be scanned or
 skipped.
 
 
@@ -669,5 +669,5 @@ Turn OFF a whitelist by an empty echo command:
 
 	echo > /sys/devices/system/edac/pci/pci_parity_whitelist
 
-and any previous blacklist will be utililzed.
+and any previous blacklist will be utilized.
 

trunk/Documentation/filesystems/00-INDEX

@@ -1,27 +1,47 @@
 00-INDEX
 	- this file (info on some of the filesystems supported by linux).
+Exporting
+	- explanation of how to make filesystems exportable.
 Locking
 	- info on locking rules as they pertain to Linux VFS.
 adfs.txt
 	- info and mount options for the Acorn Advanced Disc Filing System.
+afs.txt
+	- info and examples for the distributed AFS (Andrew File System) fs.
 affs.txt
 	- info and mount options for the Amiga Fast File System.
+automount-support.txt
+	- information about filesystem automount support.
+befs.txt
+	- information about the BeOS filesystem for Linux.
 bfs.txt
 	- info for the SCO UnixWare Boot Filesystem (BFS).
 cifs.txt
-	- description of the CIFS filesystem
+	- description of the CIFS filesystem.
 coda.txt
 	- description of the CODA filesystem.
 configfs/
 	- directory containing configfs documentation and example code.
 cramfs.txt
-	- info on the cram filesystem for small storage (ROMs etc)
+	- info on the cram filesystem for small storage (ROMs etc).
+dentry-locking.txt
+	- info on the RCU-based dcache locking model.
 devfs/
 	- directory containing devfs documentation.
+directory-locking
+	- info about the locking scheme used for directory operations.
 dlmfs.txt
 	- info on the userspace interface to the OCFS2 DLM.
 ext2.txt
 	- info, mount options and specifications for the Ext2 filesystem.
+ext3.txt
+	- info, mount options and specifications for the Ext3 filesystem.
+files.txt
+	- info on file management in the Linux kernel.
+fuse.txt
+	- info on the Filesystem in User SpacE including mount options.
+hfs.txt
+	- info on the Macintosh HFS Filesystem for Linux.
 hpfs.txt
 	- info and mount options for the OS/2 HPFS.
 isofs.txt
@@ -32,23 +52,43 @@ ncpfs.txt
 	- info on Novell Netware(tm) filesystem using NCP protocol.
 ntfs.txt
 	- info and mount options for the NTFS filesystem (Windows NT).
-proc.txt
-	- info on Linux's /proc filesystem.
 ocfs2.txt
 	- info and mount options for the OCFS2 clustered filesystem.
+porting
+	- various information on filesystem porting.
+proc.txt
+	- info on Linux's /proc filesystem.
+ramfs-rootfs-initramfs.txt
+	- info on the 'in memory' filesystems ramfs, rootfs and initramfs.
+reiser4.txt
+	- info on the Reiser4 filesystem based on dancing tree algorithms.
+relayfs.txt
+	- info on relayfs, for efficient streaming from kernel to user space.
 romfs.txt
-	- Description of the ROMFS filesystem.
+	- description of the ROMFS filesystem.
 smbfs.txt
-	- info on using filesystems with the SMB protocol (Windows 3.11 and NT)
+	- info on using filesystems with the SMB protocol (Win 3.11 and NT).
+spufs.txt
+	- info and mount options for the SPU filesystem used on Cell.
+sysfs-pci.txt
+	- info on accessing PCI device resources through sysfs.
+sysfs.txt
+	- info on sysfs, a ram-based filesystem for exporting kernel objects.
 sysv-fs.txt
 	- info on the SystemV/V7/Xenix/Coherent filesystem.
+tmpfs.txt
+	- info on tmpfs, a filesystem that holds all files in virtual memory.
 udf.txt
 	- info and mount options for the UDF filesystem.
 ufs.txt
 	- info on the ufs filesystem.
+v9fs.txt
+	- v9fs is a Unix implementation of the Plan 9 9p remote fs protocol.
 vfat.txt
 	- info on using the VFAT filesystem used in Windows NT and Windows 95
 vfs.txt
-	- Overview of the Virtual File System
+	- overview of the Virtual File System
 xfs.txt
 	- info and mount options for the XFS filesystem.
+xip.txt
+	- info on execute-in-place for file mappings.

trunk/Documentation/ioctl-number.txt

@@ -78,8 +78,6 @@ Code	Seq#	Include File		Comments
 '#'	00-3F	IEEE 1394 Subsystem	Block for the entire subsystem
 '1'	00-1F	<linux/timepps.h>	PPS kit from Ulrich Windl
 					<ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/PPS/>
-'6'	00-10	<asm-i386/processor.h>	Intel IA32 microcode update driver
-					<mailto:tigran@veritas.com>
 '8'	all				SNP8023 advanced NIC card
 					<mailto:mcr@solidum.com>
 'A'	00-1F	linux/apm_bios.h

trunk/Documentation/m68k/README.buddha

@@ -29,7 +29,7 @@ address is written to $4a, then the whole Byte is written to
 $48, while it doesn't matter how often you're writing to $4a
 as  long as $48 is not touched.  After $48 has been written,
 the  whole card disappears from $e8 and is mapped to the new
-address just written.  Make shure $4a is written before $48,
+address just written.  Make sure $4a is written before $48,
 otherwise your chance is only 1:16 to find the board :-).
 
 The local memory-map is even active when mapped to $e8:

trunk/Documentation/networking/ifenslave.c

@@ -87,7 +87,7 @@
  *	   would fail and generate an error message in the system log.
  * 	 - For opt_c: slave should not be set to the master's setting
  *	   while it is running. It was already set during enslave. To
- *	   simplify things, it is now handeled separately.
+ *	   simplify things, it is now handled separately.
  *
  *    - 2003/12/01 - Shmulik Hen <shmulik.hen at intel dot com>
  *	 - Code cleanup and style changes