---

yaml
---
r: 259065
b: refs/heads/master
c: 45d1564
h: refs/heads/master
i:
  259063: 93356e6
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 91d44d99992ff2587104df5760bfffbb3564b3c2
+refs/heads/master: 45d1564cceea8105c51b065acc8ec1312b81fbc1

trunk/.gitignore

@@ -45,11 +45,6 @@ modules.builtin
 /Module.markers
 /Module.symvers
 
-#
-# Debian directory (make deb-pkg)
-#
-/debian/
-
 #
 # git files that we don't want to ignore even it they are dot-files
 #

trunk/.mailmap

@@ -73,7 +73,8 @@ Linas Vepstas <linas@austin.ibm.com>
 Mark Brown <broonie@sirena.org.uk>
 Matthieu CASTET <castet.matthieu@free.fr>
 Mayuresh Janorkar <mayur@ti.com>
-Michael Buesch <m@bues.ch>
+Michael Buesch <mb@bu3sch.de>
+Michael Buesch <mbuesch@freenet.de>
 Michel Dänzer <michel@tungstengraphics.com>
 Mitesh shah <mshah@teja.com>
 Morten Welinder <terra@gnome.org>

trunk/Documentation/ABI/obsolete/proc-pid-oom_adj

@@ -14,7 +14,7 @@ Why:	/proc/<pid>/oom_adj allows userspace to influence the oom killer's
 
 	A much more powerful interface, /proc/<pid>/oom_score_adj, was
 	introduced with the oom killer rewrite that allows users to increase or
-	decrease the badness score linearly.  This interface will replace
+	decrease the badness() score linearly.  This interface will replace
 	/proc/<pid>/oom_adj.
 
 	A warning will be emitted to the kernel log if an application uses this

trunk/Documentation/DocBook/v4l/io.xml

@@ -210,7 +210,7 @@ for (i = 0; i < reqbuf.count; i++)
       <programlisting>
 &v4l2-requestbuffers; reqbuf;
 /* Our current format uses 3 planes per buffer */
-#define FMT_NUM_PLANES = 3
+#define FMT_NUM_PLANES = 3;
 
 struct {
 	void *start[FMT_NUM_PLANES];

trunk/Documentation/RCU/NMI-RCU.txt

@@ -5,8 +5,8 @@ Although RCU is usually used to protect read-mostly data structures,
 it is possible to use RCU to provide dynamic non-maskable interrupt
 handlers, as well as dynamic irq handlers.  This document describes
 how to do this, drawing loosely from Zwane Mwaikambo's NMI-timer
-work in "arch/x86/oprofile/nmi_timer_int.c" and in
-"arch/x86/kernel/traps.c".
+work in "arch/i386/oprofile/nmi_timer_int.c" and in
+"arch/i386/kernel/traps.c".
 
 The relevant pieces of code are listed below, each followed by a
 brief explanation.

trunk/Documentation/SubmitChecklist

@@ -53,8 +53,8 @@ kernel patches.
 
 12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
     CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
-    CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_ATOMIC_SLEEP, CONFIG_PROVE_RCU
-    and CONFIG_DEBUG_OBJECTS_RCU_HEAD all simultaneously enabled.
+    CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_ATOMIC_SLEEP all simultaneously
+    enabled.
 
 13: Has been build- and runtime tested with and without CONFIG_SMP and
     CONFIG_PREEMPT.

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

@@ -8,13 +8,10 @@ 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, S3C2416, S3C2440, S3C2442, S3C2443 and S3C2450 devices
+  S3C2412, S3C2413, S3C2416 S3C2440, S3C2442, S3C2443 and S3C2450 devices
   are supported.
 
-  Support for the S3C2400 and S3C24A0 series was never completed and the
-  corresponding code has been removed after a while.  If someone wishes to
-  revive this effort, partial support can be retrieved from earlier Linux
-  versions.
+  Support for the S3C2400 and S3C24A0 series are in progress.
 
   The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
   included under the arch/arm/mach-s3c2416 directory. Note, whilst core

trunk/Documentation/block/queue-sysfs.txt

@@ -45,13 +45,9 @@ device.
 
 rq_affinity (RW)
 ----------------
-If this option is '1', the block layer will migrate request completions to the
-cpu "group" that originally submitted the request. For some workloads this
-provides a significant reduction in CPU cycles due to caching effects.
-
-For storage configurations that need to maximize distribution of completion
-processing setting this option to '2' forces the completion to run on the
-requesting cpu (bypassing the "group" aggregation logic).
+If this option is enabled, the block layer will migrate request completions
+to the CPU that originally submitted the request. For some workloads
+this provides a significant reduction in CPU cycles due to caching effects.
 
 scheduler (RW)
 --------------

trunk/Documentation/blockdev/README.DAC960

@@ -214,7 +214,7 @@ replacing "/usr/src" with wherever you keep your Linux kernel source tree:
   make config
   make bzImage (or zImage)
 
-Then install "arch/x86/boot/bzImage" or "arch/x86/boot/zImage" as your
+Then install "arch/i386/boot/bzImage" or "arch/i386/boot/zImage" as your
 standard kernel, run lilo if appropriate, and reboot.
 
 To create the necessary devices in /dev, the "make_rd" script included in

trunk/Documentation/blockdev/ramdisk.txt

@@ -64,9 +64,9 @@ the RAM disk dynamically grows as data is being written into it, a size field
 is not required. Bits 11 to 13 are not currently used and may as well be zero.
 These numbers are no magical secrets, as seen below:
 
-./arch/x86/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK     0x07FF
-./arch/x86/kernel/setup.c:#define RAMDISK_PROMPT_FLAG          0x8000
-./arch/x86/kernel/setup.c:#define RAMDISK_LOAD_FLAG            0x4000
+./arch/i386/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK     0x07FF
+./arch/i386/kernel/setup.c:#define RAMDISK_PROMPT_FLAG          0x8000
+./arch/i386/kernel/setup.c:#define RAMDISK_LOAD_FLAG            0x4000
 
 Consider a typical two floppy disk setup, where you will have the
 kernel on disk one, and have already put a RAM disk image onto disk #2.
@@ -85,7 +85,7 @@ The command line equivalent is: "prompt_ramdisk=1"
 Putting that together gives 2^15 + 2^14 + 0 = 49152 for an rdev word.
 So to create disk one of the set, you would do:
 
-	/usr/src/linux# cat arch/x86/boot/zImage > /dev/fd0
+	/usr/src/linux# cat arch/i386/boot/zImage > /dev/fd0
 	/usr/src/linux# rdev /dev/fd0 /dev/fd0
 	/usr/src/linux# rdev -r /dev/fd0 49152
 

trunk/Documentation/cpu-freq/cpu-drivers.txt

@@ -168,7 +168,7 @@ in-chipset dynamic frequency switching to policy->min, the upper limit
 to policy->max, and -if supported- select a performance-oriented
 setting when policy->policy is CPUFREQ_POLICY_PERFORMANCE, and a
 powersaving-oriented setting when CPUFREQ_POLICY_POWERSAVE. Also check
-the reference implementation in drivers/cpufreq/longrun.c
+the reference implementation in arch/i386/kernel/cpu/cpufreq/longrun.c
 
 
 

trunk/Documentation/feature-removal-schedule.txt

@@ -184,7 +184,7 @@ Why:	/proc/<pid>/oom_adj allows userspace to influence the oom killer's
 
 	A much more powerful interface, /proc/<pid>/oom_score_adj, was
 	introduced with the oom killer rewrite that allows users to increase or
-	decrease the badness score linearly.  This interface will replace
+	decrease the badness() score linearly.  This interface will replace
 	/proc/<pid>/oom_adj.
 
 	A warning will be emitted to the kernel log if an application uses this
@@ -199,7 +199,7 @@ Files:	drivers/staging/cs5535_gpio/*
 Check:	drivers/staging/cs5535_gpio/cs5535_gpio.c
 Why:	A newer driver replaces this; it is drivers/gpio/cs5535-gpio.c, and
 	integrates with the Linux GPIO subsystem.  The old driver has been
-	moved to staging, and will be removed altogether around 3.0.
+	moved to staging, and will be removed altogether around 2.6.40.
 	Please test the new driver, and ensure that the functionality you
 	need and any bugfixes from the old driver are available in the new
 	one.
@@ -294,7 +294,7 @@ When:	The schedule was July 2008, but it was decided that we are going to keep t
 Why:	The support code for the old firmware hurts code readability/maintainability
 	and slightly hurts runtime performance. Bugfixes for the old firmware
 	are not provided by Broadcom anymore.
-Who:	Michael Buesch <m@bues.ch>
+Who:	Michael Buesch <mb@bu3sch.de>
 
 ---------------------------
 
@@ -430,7 +430,7 @@ Who:	Avi Kivity <avi@redhat.com>
 ----------------------------
 
 What:	iwlwifi 50XX module parameters
-When:	3.0
+When:	2.6.40
 Why:	The "..50" modules parameters were used to configure 5000 series and
 	up devices; different set of module parameters also available for 4965
 	with same functionalities. Consolidate both set into single place
@@ -441,7 +441,7 @@ Who:	Wey-Yi Guy <wey-yi.w.guy@intel.com>
 ----------------------------
 
 What:	iwl4965 alias support
-When:	3.0
+When:	2.6.40
 Why:	Internal alias support has been present in module-init-tools for some
 	time, the MODULE_ALIAS("iwl4965") boilerplate aliases can be removed
 	with no impact.
@@ -482,7 +482,7 @@ Who:	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
 ----------------------------
 
 What:	iwlwifi disable_hw_scan module parameters
-When:	3.0
+When:	2.6.40
 Why:	Hareware scan is the prefer method for iwlwifi devices for
 	scanning operation. Remove software scan support for all the
 	iwlwifi devices.
@@ -491,6 +491,16 @@ Who:	Wey-Yi Guy <wey-yi.w.guy@intel.com>
 
 ----------------------------
 
+What:   access to nfsd auth cache through sys_nfsservctl or '.' files
+        in the 'nfsd' filesystem.
+When:   2.6.40
+Why:    This is a legacy interface which have been replaced by a more
+        dynamic cache.  Continuing to maintain this interface is an
+        unnecessary burden.
+Who:    NeilBrown <neilb@suse.de>
+
+----------------------------
+
 What:	Legacy, non-standard chassis intrusion detection interface.
 When:	June 2011
 Why:	The adm9240, w83792d and w83793 hardware monitoring drivers have
@@ -508,6 +518,22 @@ Files:	net/netfilter/xt_connlimit.c
 
 ----------------------------
 
+What:	noswapaccount kernel command line parameter
+When:	2.6.40
+Why:	The original implementation of memsw feature enabled by
+	CONFIG_CGROUP_MEM_RES_CTLR_SWAP could be disabled by the noswapaccount
+	kernel parameter (introduced in 2.6.29-rc1). Later on, this decision
+	turned out to be not ideal because we cannot have the feature compiled
+	in and disabled by default and let only interested to enable it
+	(e.g. general distribution kernels might need it). Therefore we have
+	added swapaccount[=0|1] parameter (introduced in 2.6.37) which provides
+	the both possibilities. If we remove noswapaccount we will have
+	less command line parameters with the same functionality and we
+	can also cleanup the parameter handling a bit ().
+Who:	Michal Hocko <mhocko@suse.cz>
+
+----------------------------
+
 What:	ipt_addrtype match include file
 When:	2012
 Why:	superseded by xt_addrtype
@@ -526,23 +552,23 @@ Who:	Jean Delvare <khali@linux-fr.org>
 ----------------------------
 
 What:	Support for UVCIOC_CTRL_ADD in the uvcvideo driver
-When:	3.2
+When:	2.6.42
 Why:	The information passed to the driver by this ioctl is now queried
 	dynamically from the device.
 Who:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
 
 ----------------------------
 
 What:	Support for UVCIOC_CTRL_MAP_OLD in the uvcvideo driver
-When:	3.2
+When:	2.6.42
 Why:	Used only by applications compiled against older driver versions.
 	Superseded by UVCIOC_CTRL_MAP which supports V4L2 menu controls.
 Who:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
 
 ----------------------------
 
 What:	Support for UVCIOC_CTRL_GET and UVCIOC_CTRL_SET in the uvcvideo driver
-When:	3.2
+When:	2.6.42
 Why:	Superseded by the UVCIOC_CTRL_QUERY ioctl.
 Who:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
 

trunk/Documentation/filesystems/Locking

@@ -52,7 +52,7 @@ ata *);
 	void (*put_link) (struct dentry *, struct nameidata *, void *);
 	void (*truncate) (struct inode *);
 	int (*permission) (struct inode *, int, unsigned int);
-	int (*get_acl)(struct inode *, int);
+	int (*check_acl)(struct inode *, int);
 	int (*setattr) (struct dentry *, struct iattr *);
 	int (*getattr) (struct vfsmount *, struct dentry *, struct kstat *);
 	int (*setxattr) (struct dentry *, const char *,const void *,size_t,int);
@@ -80,7 +80,7 @@ put_link:	no
 truncate:	yes		(see below)
 setattr:	yes
 permission:	no (may not block if called in rcu-walk mode)
-get_acl:	no
+check_acl:	no
 getattr:	no
 setxattr:	yes
 getxattr:	no
@@ -338,21 +338,21 @@ fl_release_private:	maybe		no
 
 ----------------------- lock_manager_operations ---------------------------
 prototypes:
-	int (*lm_compare_owner)(struct file_lock *, struct file_lock *);
-	void (*lm_notify)(struct file_lock *);  /* unblock callback */
-	int (*lm_grant)(struct file_lock *, struct file_lock *, int);
-	void (*lm_release_private)(struct file_lock *);
-	void (*lm_break)(struct file_lock *); /* break_lease callback */
-	int (*lm_change)(struct file_lock **, int);
+	int (*fl_compare_owner)(struct file_lock *, struct file_lock *);
+	void (*fl_notify)(struct file_lock *);  /* unblock callback */
+	int (*fl_grant)(struct file_lock *, struct file_lock *, int);
+	void (*fl_release_private)(struct file_lock *);
+	void (*fl_break)(struct file_lock *); /* break_lease callback */
+	int (*fl_change)(struct file_lock **, int);
 
 locking rules:
 			file_lock_lock	may block
-lm_compare_owner:	yes		no
-lm_notify:		yes		no
-lm_grant:		no		no
-lm_release_private:	maybe		no
-lm_break:		yes		no
-lm_change		yes		no
+fl_compare_owner:	yes		no
+fl_notify:		yes		no
+fl_grant:		no		no
+fl_release_private:	maybe		no
+fl_break:		yes		no
+fl_change		yes		no
 
 --------------------------- buffer_head -----------------------------------
 prototypes: