---

yaml
---
r: 110698
b: refs/heads/master
c: 07dd20e
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: f6bccf695431da0e9bd773550ae91b8cb9ffb227
+refs/heads/master: 07dd20e0324f4d3e33bde1944d4f7771a09c498c

trunk/.mailmap

@@ -96,6 +96,4 @@ Tejun Heo <htejun@gmail.com>
 Thomas Graf <tgraf@suug.ch>
 Tony Luck <tony.luck@intel.com>
 Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
-Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
-Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
 Valdis Kletnieks <Valdis.Kletnieks@vt.edu>

trunk/Documentation/00-INDEX

@@ -251,6 +251,8 @@ mono.txt
 	- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
 moxa-smartio
 	- file with info on installing/using Moxa multiport serial driver.
+mtrr.txt
+	- how to use PPro Memory Type Range Registers to increase performance.
 mutex-design.txt
 	- info on the generic mutex subsystem.
 namespaces/

trunk/Documentation/DMA-API.txt

@@ -337,7 +337,7 @@ With scatterlists, you use the resulting mapping like this:
 	int i, count = dma_map_sg(dev, sglist, nents, direction);
 	struct scatterlist *sg;
 
-	for_each_sg(sglist, sg, count, i) {
+	for (i = 0, sg = sglist; i < count; i++, sg++) {
 		hw_address[i] = sg_dma_address(sg);
 		hw_len[i] = sg_dma_len(sg);
 	}

trunk/Documentation/DMA-mapping.txt

@@ -740,7 +740,7 @@ failure can be determined by:
 	dma_addr_t dma_handle;
 
 	dma_handle = pci_map_single(pdev, addr, size, direction);
-	if (pci_dma_mapping_error(pdev, dma_handle)) {
+	if (pci_dma_mapping_error(dma_handle)) {
 		/*
 		 * reduce current DMA mapping usage,
 		 * delay and try again later or

trunk/Documentation/DocBook/kernel-api.tmpl

@@ -364,10 +364,6 @@ X!Edrivers/pnp/system.c
 !Eblock/blk-barrier.c
 !Eblock/blk-tag.c
 !Iblock/blk-tag.c
-!Eblock/blk-integrity.c
-!Iblock/blktrace.c
-!Iblock/genhd.c
-!Eblock/genhd.c
   </chapter>
 
   <chapter id="chrdev">

trunk/Documentation/HOWTO

@@ -77,8 +77,7 @@ documentation files are also added which explain how to use the feature.
 When a kernel change causes the interface that the kernel exposes to
 userspace to change, it is recommended that you send the information or
 a patch to the manual pages explaining the change to the manual pages
-maintainer at mtk.manpages@gmail.com, and CC the list
-linux-api@vger.kernel.org.
+maintainer at mtk.manpages@gmail.com.
 
 Here is a list of files that are in the kernel source tree that are
 required reading:

trunk/Documentation/SubmitChecklist

@@ -67,8 +67,6 @@ kernel patches.
 
 19: All new userspace interfaces are documented in Documentation/ABI/.
     See Documentation/ABI/README for more information.
-    Patches that change userspace interfaces should be CCed to
-    linux-api@vger.kernel.org.
 
 20: Check that it all passes `make headers_check'.
 

trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt

@@ -13,21 +13,6 @@ Introduction
   data-sheet/users manual to find out the complete list.
 
 
-GPIOLIB
--------
-
-  With the event of the GPIOLIB in drivers/gpio, support for some
-  of the GPIO functions such as reading and writing a pin will
-  be removed in favour of this common access method.
-
-  Once all the extant drivers have been converted, the functions
-  listed below will be removed (they may be marked as __deprecated
-  in the near future).
-
-  - s3c2410_gpio_getpin
-  - s3c2410_gpio_setpin
-
-
 Headers
 -------
 

trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt

@@ -8,10 +8,9 @@ Introduction
 
   The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
   by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
-  S3C2412, S3C2413, S3C2440, S3C2442 and S3C2443 devices are supported.
-
-  Support for the S3C2400 and S3C24A0 series are in progress.
+  S3C2412, S3C2413, S3C2440 and S3C2442 devices are supported.
 
+  Support for the S3C2400 series is in progress.
 
 Configuration
 -------------
@@ -39,22 +38,6 @@ Layout
   Register, kernel and platform data definitions are held in the
   arch/arm/mach-s3c2410 directory./include/mach
 
-arch/arm/plat-s3c24xx:
-
-  Files in here are either common to all the s3c24xx family,
-  or are common to only some of them with names to indicate this
-  status. The files that are not common to all are generally named
-  with the initial cpu they support in the series to ensure a short
-  name without any possibility of confusion with newer devices.
-
-  As an example, initially s3c244x would cover s3c2440 and s3c2442, but
-  with the s3c2443 which does not share many of the same drivers in
-  this directory, the name becomes invalid. We stick to s3c2440-<x>
-  to indicate a driver that is s3c2440 and s3c2442 compatible.
-
-  This does mean that to find the status of any given SoC, a number
-  of directories may need to be searched.
-
 
 Machines
 --------
@@ -176,17 +159,6 @@ NAND
   For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
 
 
-SD/MMC
-------
-
-  The SD/MMC hardware pre S3C2443 is supported in the current
-  kernel, the driver is drivers/mmc/host/s3cmci.c and supports
-  1 and 4 bit SD or MMC cards.
-
-  The SDIO behaviour of this driver has not been fully tested. There is no
-  current support for hardware SDIO interrupts.
-
-
 Serial
 ------
 
@@ -206,9 +178,6 @@ GPIO
   The core contains support for manipulating the GPIO, see the
   documentation in GPIO.txt in the same directory as this file.
 
-  Newer kernels carry GPIOLIB, and support is being moved towards
-  this with some of the older support in line to be removed.
-
 
 Clock Management
 ----------------

trunk/Documentation/block/deadline-iosched.txt

@@ -30,18 +30,12 @@ write_expire	(in ms)
 Similar to read_expire mentioned above, but for writes.
 
 
-fifo_batch	(number of requests)
+fifo_batch
 ----------
 
-Requests are grouped into ``batches'' of a particular data direction (read or
-write) which are serviced in increasing sector order.  To limit extra seeking,
-deadline expiries are only checked between batches.  fifo_batch controls the
-maximum number of requests per batch.
-
-This parameter tunes the balance between per-request latency and aggregate
-throughput.  When low latency is the primary concern, smaller is better (where
-a value of 1 yields first-come first-served behaviour).  Increasing fifo_batch
-generally improves throughput, at the cost of latency variation.
+When a read request expires its deadline, we must move some requests from
+the sorted io scheduler list to the block device dispatch queue. fifo_batch
+controls how many requests we move.
 
 
 writes_starved	(number of dispatches)

trunk/Documentation/cdrom/ide-cd

@@ -145,7 +145,8 @@ useful for reading photocds.
 
 To play an audio CD, you should first unmount and remove any data
 CDROM.  Any of the CDROM player programs should then work (workman,
-workbone, cdplayer, etc.).
+workbone, cdplayer, etc.).  Lacking anything else, you could use the
+cdtester program in Documentation/cdrom/sbpcd.
 
 On a few drives, you can read digital audio directly using a program
 such as cdda2wav.  The only types of drive which I've heard support

trunk/Documentation/cpu-freq/index.txt

@@ -35,9 +35,11 @@ Mailing List
 ------------
 There is a CPU frequency changing CVS commit and general list where
 you can report bugs, problems or submit patches. To post a message,
-send an email to cpufreq@vger.kernel.org, to subscribe go to
-http://vger.kernel.org/vger-lists.html#cpufreq and follow the
-instructions there.
+send an email to cpufreq@lists.linux.org.uk, to subscribe go to
+http://lists.linux.org.uk/mailman/listinfo/cpufreq. Previous post to the
+mailing list are available to subscribers at
+http://lists.linux.org.uk/mailman/private/cpufreq/.
+
 
 Links
 -----
@@ -48,7 +50,7 @@ how to access the CVS repository:
 * http://cvs.arm.linux.org.uk/
 
 the CPUFreq Mailing list:
-* http://vger.kernel.org/vger-lists.html#cpufreq
+* http://lists.linux.org.uk/mailman/listinfo/cpufreq
 
 Clock and voltage scaling for the SA-1100:
 * http://www.lartmaker.nl/projects/scaling

trunk/Documentation/cpusets.txt

@@ -635,16 +635,14 @@ prior 'mems' setting, will not be moved.
 
 There is an exception to the above.  If hotplug functionality is used
 to remove all the CPUs that are currently assigned to a cpuset,
-then all the tasks in that cpuset will be moved to the nearest ancestor
-with non-empty cpus.  But the moving of some (or all) tasks might fail if
-cpuset is bound with another cgroup subsystem which has some restrictions
-on task attaching.  In this failing case, those tasks will stay
-in the original cpuset, and the kernel will automatically update
-their cpus_allowed to allow all online CPUs.  When memory hotplug
-functionality for removing Memory Nodes is available, a similar exception
-is expected to apply there as well.  In general, the kernel prefers to
-violate cpuset placement, over starving a task that has had all
-its allowed CPUs or Memory Nodes taken offline.
+then the kernel will automatically update the cpus_allowed of all
+tasks attached to CPUs in that cpuset to allow all CPUs.  When memory
+hotplug functionality for removing Memory Nodes is available, a
+similar exception is expected to apply there as well.  In general,
+the kernel prefers to violate cpuset placement, over starving a task
+that has had all its allowed CPUs or Memory Nodes taken offline.  User
+code should reconfigure cpusets to only refer to online CPUs and Memory
+Nodes when using hotplug to add or remove such resources.
 
 There is a second exception to the above.  GFP_ATOMIC requests are
 kernel internal allocations that must be satisfied, immediately.

trunk/Documentation/dontdiff

@@ -5,8 +5,6 @@
 *.css
 *.dvi
 *.eps
-*.fw.gen.S
-*.fw
 *.gif
 *.grep
 *.grp

trunk/Documentation/feature-removal-schedule.txt

@@ -322,11 +322,3 @@ Why:  Accounting can now be enabled/disabled without kernel recompilation.
       controlled by a kernel/module/sysfs/sysctl parameter.
 Who:  Krzysztof Piotr Oledzki <ole@ans.pl>
 
----------------------------
-
-What: ide-scsi (BLK_DEV_IDESCSI)
-When: 2.6.29
-Why:  The 2.6 kernel supports direct writing to ide CD drives, which
-      eliminates the need for ide-scsi. The new method is more
-      efficient in every way.
-Who:  FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>

trunk/Documentation/filesystems/Locking

@@ -144,8 +144,8 @@ prototypes:
 	void (*kill_sb) (struct super_block *);
 locking rules:
 		may block	BKL
-get_sb		yes		no
-kill_sb		yes		no
+get_sb		yes		yes
+kill_sb		yes		yes
 
 ->get_sb() returns error or 0 with locked superblock attached to the vfsmount
 (exclusive on ->s_umount).
@@ -409,12 +409,12 @@ ioctl:			yes	(see below)
 unlocked_ioctl:		no	(see below)
 compat_ioctl:		no
 mmap:			no
-open:			no
+open:			maybe	(see below)
 flush:			no
 release:		no
 fsync:			no	(see below)
 aio_fsync:		no
-fasync:			no
+fasync:			yes	(see below)
 lock:			yes
 readv:			no
 writev:			no
@@ -431,6 +431,13 @@ For many filesystems, it is probably safe to acquire the inode
 semaphore.  Note some filesystems (i.e. remote ones) provide no
 protection for i_size so you will need to use the BKL.
 
+->open() locking is in-transit: big lock partially moved into the methods.
+The only exception is ->open() in the instances of file_operations that never
+end up in ->i_fop/->proc_fops, i.e. ones that belong to character devices
+(chrdev_open() takes lock before replacing ->f_op and calling the secondary
+method. As soon as we fix the handling of module reference counters all
+instances of ->open() will be called without the BKL.
+
 Note: ext2_release() was *the* source of contention on fs-intensive
 loads and dropping BKL on ->release() helps to get rid of that (we still
 grab BKL for cases when we close a file that had been opened r/w, but that

trunk/Documentation/filesystems/ext4.txt

@@ -26,12 +26,6 @@ Mailing list: linux-ext4@vger.kernel.org
 
     git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
 
-  - Note that it is highly important to install the mke2fs.conf file
-    that comes with the e2fsprogs 1.41.x sources in /etc/mke2fs.conf. If
-    you have edited the /etc/mke2fs.conf file installed on your system,
-    you will need to merge your changes with the version from e2fsprogs
-    1.41.x.
-
   - Create a new filesystem using the ext4dev filesystem type:
 
     	# mke2fs -t ext4dev /dev/hda1

trunk/Documentation/filesystems/ntfs.txt

@@ -40,7 +40,7 @@ Web site
 ========
 
 There is plenty of additional information on the linux-ntfs web site
-at http://www.linux-ntfs.org/
+at http://linux-ntfs.sourceforge.net/
 
 The web site has a lot of additional information, such as a comprehensive
 FAQ, documentation on the NTFS on-disk format, information on the Linux-NTFS
@@ -272,7 +272,7 @@ And you would know that /dev/hda2 has a size of 37768814 - 4209030 + 1 =
 For Win2k and later dynamic disks, you can for example use the ldminfo utility
 which is part of the Linux LDM tools (the latest version at the time of
 writing is linux-ldm-0.0.8.tar.bz2).  You can download it from:
-	http://www.linux-ntfs.org/
+	http://linux-ntfs.sourceforge.net/downloads.html
 Simply extract the downloaded archive (tar xvjf linux-ldm-0.0.8.tar.bz2), go
 into it (cd linux-ldm-0.0.8) and change to the test directory (cd test).  You
 will find the precompiled (i386) ldminfo utility there.  NOTE: You will not be