---

yaml
---
r: 24787
b: refs/heads/master
c: aec5c3c
h: refs/heads/master
i:
  24785: 8be089e
  24783: 0aa4378
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 63e8d9114dab88c101be2372cb1f83a4fe74d9c1
+refs/heads/master: aec5c3c1a929d7d79a420e943285cf3ba26a7c0d

trunk/CREDITS

@@ -1127,10 +1127,8 @@ S: Carnegie, Pennsylvania 15106-4304
 S: USA
 
 N: Philip Gladstone
-E: philip@gladstonefamily.net
+E: philip@raptor.com
 D: Kernel / timekeeping stuff
-S: Carlisle, MA 01741
-S: USA
 
 N: Jan-Benedict Glaw
 E: jbglaw@lug-owl.de
@@ -2009,14 +2007,13 @@ S: University of Stuttgart, Germany and
 S: Ecole Nationale Superieure des Telecommunications, Paris
 
 N: Jamie Lokier
-E: jamie@shareable.org
-W: http://www.shareable.org/
+E: jamie@imbolc.ucc.ie
 D: Reboot-through-BIOS for broken 486 motherboards
-D: Parport fixes, futex improvements
-D: First instruction of x86 sysenter path :)
-S: 51 Sunningwell Road
+D: Some parport fixes
+S: 11 Goodson Walk
+S: Marston
 S: Oxford
-S: OX1 4SZ
+S: OX3 0HX
 S: United Kingdom
 
 N: Mark Lord
@@ -3743,11 +3740,10 @@ D: Mylex DAC960 PCI RAID driver
 D: Miscellaneous kernel fixes
 
 N: Alessandro Zummo
-E: a.zummo@towertech.it
+E: azummo@ita.flashnet.it
+W: http://freepage.logicom.it/azummo/
 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,8 +199,6 @@ 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/DocBook/Makefile

@@ -28,7 +28,7 @@ PS_METHOD	= $(prefer-db2x)
 
 ###
 # The targets that may be used.
-PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs
+.PHONY:	xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs
 
 BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
 xmldocs: $(BOOKS)
@@ -211,9 +211,3 @@ clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS))
 
 #man put files in man subdir - traverse down
 subdir- := man/
-
-
-# Declare the contents of the .PHONY variable as phony.  We keep that
-# information in a variable se we can use it in if_changed and friends.
-
-.PHONY: $(PHONY)

trunk/Documentation/RCU/whatisRCU.txt

@@ -360,7 +360,7 @@ uses of RCU may be found in listRCU.txt, arrayRCU.txt, and NMI-RCU.txt.
 		struct foo *new_fp;
 		struct foo *old_fp;
 
-		new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
+		new_fp = kmalloc(sizeof(*fp), GFP_KERNEL);
 		spin_lock(&foo_mutex);
 		old_fp = gbl_foo;
 		*new_fp = *old_fp;
@@ -461,7 +461,7 @@ The foo_update_a() function might then be written as follows:
 		struct foo *new_fp;
 		struct foo *old_fp;
 
-		new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
+		new_fp = kmalloc(sizeof(*fp), GFP_KERNEL);
 		spin_lock(&foo_mutex);
 		old_fp = gbl_foo;
 		*new_fp = *old_fp;
@@ -605,7 +605,7 @@ are the same as those shown in the preceding section, so they are omitted.
 	{
 		int cpu;
 
-		for_each_possible_cpu(cpu)
+		for_each_cpu(cpu)
 			run_on(cpu);
 	}
 

trunk/Documentation/aoe/mkdevs.sh

@@ -27,8 +27,6 @@ rm -f $dir/discover
 mknod -m 0200 $dir/discover c $MAJOR 3
 rm -f $dir/interfaces
 mknod -m 0200 $dir/interfaces c $MAJOR 4
-rm -f $dir/revalidate
-mknod -m 0200 $dir/revalidate c $MAJOR 5
 
 export n_partitions
 mkshelf=`echo $0 | sed 's!mkdevs!mkshelf!'`

trunk/Documentation/aoe/udev.txt

@@ -18,7 +18,6 @@
 SUBSYSTEM="aoe", KERNEL="discover",	NAME="etherd/%k", GROUP="disk", MODE="0220"
 SUBSYSTEM="aoe", KERNEL="err",		NAME="etherd/%k", GROUP="disk", MODE="0440"
 SUBSYSTEM="aoe", KERNEL="interfaces",	NAME="etherd/%k", GROUP="disk", MODE="0220"
-SUBSYSTEM="aoe", KERNEL="revalidate",	NAME="etherd/%k", GROUP="disk", MODE="0220"
 
 # aoe block devices     
 KERNEL="etherd*",       NAME="%k", GROUP="disk"

trunk/Documentation/arm/Booting

@@ -118,7 +118,7 @@ to store page tables.  The recommended placement is 32KiB into RAM.
 
 In either case, the following conditions must be met:
 
-- Quiesce all DMA capable devices so that memory does not get
+- Quiesce all DMA capable devicess so that memory does not get
   corrupted by bogus network packets or disk data. This will save
   you many hours of debug.
 

trunk/Documentation/arm/README

@@ -89,7 +89,7 @@ Modules
   Although modularisation is supported (and required for the FP emulator),
   each module on an ARM2/ARM250/ARM3 machine when is loaded will take
   memory up to the next 32k boundary due to the size of the pages.
-  Therefore, is modularisation on these machines really worth it?
+  Therefore, modularisation on these machines really worth it?
 
   However, ARM6 and up machines allow modules to take multiples of 4k, and
   as such Acorn RiscPCs and other architectures using these processors can

trunk/Documentation/arm/SA1100/Assabet

@@ -26,7 +26,7 @@ Installing a bootloader
 
 A couple of bootloaders able to boot Linux on Assabet are available:
 
-BLOB (http://www.lartmaker.nl/lartware/blob/)
+BLOB (http://www.lart.tudelft.nl/lartware/blob/)
 
    BLOB is a bootloader used within the LART project.  Some contributed
    patches were merged into BLOB to add support for Assabet.

trunk/Documentation/arm/SA1100/LART

@@ -11,4 +11,4 @@ is under development, with plenty of others in different stages of
 planning.
 
 The hardware designs for this board have been released under an open license;
-see the LART page at http://www.lartmaker.nl/ for more information.
+see the LART page at http://www.lart.tudelft.nl/ for more information.

trunk/Documentation/arm/Setup

@@ -58,7 +58,7 @@ below:
  video_y
 
    This describes the character position of cursor on VGA console, and
-   is otherwise unused. (should not be used for other console types, and
+   is otherwise unused. (should not used for other console types, and
    should not be used for other purposes).
 
  memc_control_reg

trunk/Documentation/block/biodoc.txt

@@ -132,18 +132,8 @@ Some new queue property settings:
 		limit. No highmem default.
 
 	blk_queue_max_sectors(q, max_sectors)
-		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.
+		Maximum size request you can handle in units of 512 byte
+		sectors. 255 default.
 
 	blk_queue_max_phys_segments(q, max_segments)
 		Maximum physical segments you can handle in a request. 128

trunk/Documentation/cachetlb.txt

@@ -362,27 +362,6 @@ 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_possible_cpu() to iterate.
+cpu_possible_map/for_each_cpu() to iterate.
 
 Never use anything other than cpumask_t to represent bitmap of CPUs.
 
 #include <linux/cpumask.h>
 
-for_each_possible_cpu     - Iterate over cpu_possible_map
+for_each_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 via sysfs. Items (attributes) are similar
+Export cpu topology info by 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,
-drivers/base/topology.c, is to export the 4 attributes.
+driver/base/topology.c, is to export the 5 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 maintenance and
+continue to operate, but with less safety. Preventive maintainence 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 add-in adapters that do NOT follow the PCI specification
+There are several addin 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 flaky
+The PCI Parity EDAC device has the ability to "skip" known flakey
 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
-laid out in a Chip-Select Row (csrowX) and Channel table (chX). There can
+layed 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 labeled 'B'
+labeled 'A' are channel 0 in this example. Slots labled '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 similarly placed, then both csrow0 and
+when 2 dual ranked DIMMs are similiaryly 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 module's version and compile date are shown here to
+	The EDAC CORE modules'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 contains.
+	that this csrow contatins.
 
 
 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 occurred on the bus on the other side of
+looked at to see if parity ocurred 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 panicking when a parity
+	This control files enables or disables panic'ing 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 hexadecimal VENDOR and DEVICE
+	be examined.  The list is a line of hexadecimel VENDOR and DEVICE
 	ID tuples:
 
 	1022:7450,1434:16a6
 
-	One or more can be inserted, separated by a comma.
+	One or more can be inserted, seperated 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 hexadecimal VENDOR and DEVICE ID tuples:
+	The list is a line of hexadecimel VENDOR and DEVICE ID tuples:
 
 	1022:7450,1434:16a6
 
-	One or more can be inserted, separated by a comma.
+	One or more can be inserted, seperated 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 currently contains,
+	To display what the whitelist current contatins,
 	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
-administrator will have to determine which devices should be scanned or
+adminstrator 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 utilized.
+and any previous blacklist will be utililzed.