---

yaml
---
r: 57445
b: refs/heads/master
c: ef6051a
h: refs/heads/master
i:
  57443: c0dd9e2
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 34750bb15687fa03ba95a0ccb1307b0727bc308b
+refs/heads/master: ef6051a90e2ad1af636e99d1d4603fdcf2adfcbe

trunk/Documentation/BUG-HUNTING

@@ -191,30 +191,6 @@ e.g. crash dump output as shown by Dave Miller.
 >        mov        0x8(%ebp), %ebx         ! %ebx = skb->sk
 >        mov        0x13c(%ebx), %eax       ! %eax = inet_sk(sk)->opt
 
-In addition, you can use GDB to figure out the exact file and line
-number of the OOPS from the vmlinux file. If you have
-CONFIG_DEBUG_INFO enabled, you can simply copy the EIP value from the
-OOPS:
-
- EIP:    0060:[<c021e50e>]    Not tainted VLI
-
-And use GDB to translate that to human-readable form:
-
-  gdb vmlinux
-  (gdb) l *0xc021e50e
-
-If you don't have CONFIG_DEBUG_INFO enabled, you use the function
-offset from the OOPS:
-
- EIP is at vt_ioctl+0xda8/0x1482
-
-And recompile the kernel with CONFIG_DEBUG_INFO enabled:
-
-  make vmlinux
-  gdb vmlinux
-  (gdb) p vt_ioctl
-  (gdb) l *(0x<address of vt_ioctl> + 0xda8)
-
 Another very useful option of the Kernel Hacking section in menuconfig is
 Debug memory allocations. This will help you see whether data has been
 initialised and not set before use etc. To see the values that get assigned

trunk/Documentation/SubmitChecklist

@@ -84,9 +84,3 @@ kernel patches.
 24: Avoid whitespace damage such as indenting with spaces or whitespace
     at the end of lines.  You can test this by feeding the patch to
     "git apply --check --whitespace=error-all"
-
-25: Check your patch for general style as detailed in
-    Documentation/CodingStyle.  Check for trivial violations with the
-    patch style checker prior to submission (scripts/checkpatch.pl).
-    You should be able to justify all violations that remain in
-    your patch.

trunk/Documentation/SubmittingPatches

@@ -118,20 +118,7 @@ then only post say 15 or so at a time and wait for review and integration.
 
 
 
-4) Style check your changes.
-
-Check your patch for basic style violations, details of which can be
-found in Documentation/CodingStyle.  Failure to do so simply wastes
-the reviewers time and will get your patch rejected, probabally
-without even being read.
-
-At a minimum you should check your patches with the patch style
-checker prior to submission (scripts/patchcheck.pl).  You should
-be able to justify all violations that remain in your patch.
-
-
-
-5) Select e-mail destination.
+4) Select e-mail destination.
 
 Look through the MAINTAINERS file and the source code, and determine
 if your change applies to a specific subsystem of the kernel, with
@@ -159,7 +146,7 @@ discussed should the patch then be submitted to Linus.
 
 
 
-6) Select your CC (e-mail carbon copy) list.
+5) Select your CC (e-mail carbon copy) list.
 
 Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
 
@@ -200,7 +187,8 @@ URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
 
 
 
-7) No MIME, no links, no compression, no attachments.  Just plain text.
+
+6) No MIME, no links, no compression, no attachments.  Just plain text.
 
 Linus and other kernel developers need to be able to read and comment
 on the changes you are submitting.  It is important for a kernel
@@ -235,9 +223,9 @@ pref("mailnews.display.disable_format_flowed_support", true);
 
 
 
-8) E-mail size.
+7) E-mail size.
 
-When sending patches to Linus, always follow step #7.
+When sending patches to Linus, always follow step #6.
 
 Large changes are not appropriate for mailing lists, and some
 maintainers.  If your patch, uncompressed, exceeds 40 kB in size,
@@ -246,7 +234,7 @@ server, and provide instead a URL (link) pointing to your patch.
 
 
 
-9) Name your kernel version.
+8) Name your kernel version.
 
 It is important to note, either in the subject line or in the patch
 description, the kernel version to which this patch applies.
@@ -256,7 +244,7 @@ Linus will not apply it.
 
 
 
-10) Don't get discouraged.  Re-submit.
+9) Don't get discouraged.  Re-submit.
 
 After you have submitted your change, be patient and wait.  If Linus
 likes your change and applies it, it will appear in the next version
@@ -282,7 +270,7 @@ When in doubt, solicit comments on linux-kernel mailing list.
 
 
 
-11) Include PATCH in the subject
+10) Include PATCH in the subject
 
 Due to high e-mail traffic to Linus, and to linux-kernel, it is common
 convention to prefix your subject line with [PATCH].  This lets Linus
@@ -291,7 +279,7 @@ e-mail discussions.
 
 
 
-12) Sign your work
+11) Sign your work
 
 To improve tracking of who did what, especially with patches that can
 percolate to their final resting place in the kernel through several
@@ -340,8 +328,7 @@ now, but you can do this to mark internal company procedures or just
 point out some special detail about the sign-off. 
 
 
-
-13) The canonical patch format
+12) The canonical patch format
 
 The canonical patch subject line is:
 
@@ -440,10 +427,6 @@ section Linus Computer Science 101.
 Nuff said.  If your code deviates too much from this, it is likely
 to be rejected without further review, and without comment.
 
-Check your patches with the patch style checker prior to submission
-(scripts/checkpatch.pl).  You should be able to justify all
-violations that remain in your patch.
-
 
 
 2) #ifdefs are ugly

trunk/Documentation/feature-removal-schedule.txt

@@ -70,7 +70,6 @@ Who:	David Miller <davem@davemloft.net>
 
 What:	Video4Linux API 1 ioctls and video_decoder.h from Video devices.
 When:	December 2006
-Files:	include/linux/video_decoder.h
 Why:	V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
 	series. The old API have lots of drawbacks and don't provide enough
 	means to work with all video and audio standards. The newer API is

trunk/Documentation/hrtimer/timer_stats.txt

@@ -2,10 +2,9 @@ timer_stats - timer usage statistics
 ------------------------------------
 
 timer_stats is a debugging facility to make the timer (ab)usage in a Linux
-system visible to kernel and userspace developers. If enabled in the config
-but not used it has almost zero runtime overhead, and a relatively small
-data structure overhead. Even if collection is enabled runtime all the
-locking is per-CPU and lookup is hashed.
+system visible to kernel and userspace developers. It is not intended for
+production usage as it adds significant overhead to the (hr)timer code and the
+(hr)timer data structures.
 
 timer_stats should be used by kernel and userspace developers to verify that
 their code does not make unduly use of timers. This helps to avoid unnecessary

trunk/Documentation/ia64/aliasing-test.c

@@ -197,7 +197,7 @@ int scan_rom(char *path, char *file)
 	return rc;
 }
 
-int main()
+main()
 {
 	int rc;
 

trunk/Documentation/kernel-parameters.txt

@@ -170,10 +170,7 @@ and is between 256 and 4096 characters. It is defined in the file
 	acpi_os_name=	[HW,ACPI] Tell ACPI BIOS the name of the OS
 			Format: To spoof as Windows 98: ="Microsoft Windows"
 
-	acpi_osi=	[HW,ACPI] Modify list of supported OS interface strings
-			acpi_osi="string1"	# add string1 -- only one string
-			acpi_osi="!string2"	# remove built-in string2
-			acpi_osi=		# disable all strings
+	acpi_osi=	[HW,ACPI] empty param disables _OSI
 
 	acpi_serialize	[HW,ACPI] force serialization of AML methods
 
@@ -1135,9 +1132,9 @@ and is between 256 and 4096 characters. It is defined in the file
 			when set.
 			Format: <int>
 
-	noaliencache	[MM, NUMA, SLAB] Disables the allocation of alien
-			caches in the slab allocator.  Saves per-node memory,
-			but will impact performance.
+	noaliencache	[MM, NUMA] Disables the allcoation of alien caches in
+			the slab allocator.  Saves per-node memory, but will
+			impact performance on real NUMA hardware.
 
 	noalign		[KNL,ARM]
 
@@ -1616,37 +1613,6 @@ and is between 256 and 4096 characters. It is defined in the file
 
 	slram=		[HW,MTD]
 
-	slub_debug	[MM, SLUB]
-			Enabling slub_debug allows one to determine the culprit
-			if slab objects become corrupted. Enabling slub_debug
-			creates guard zones around objects and poisons objects
-			when not in use. Also tracks the last alloc / free.
-			For more information see Documentation/vm/slub.txt.
-
-	slub_max_order= [MM, SLUB]
-			Determines the maximum allowed order for slabs. Setting
-			this too high may cause fragmentation.
-			For more information see Documentation/vm/slub.txt.
-
-	slub_min_objects=	[MM, SLUB]
-			The minimum objects per slab. SLUB will increase the
-			slab order up to slub_max_order to generate a
-			sufficiently big slab to satisfy the number of objects.
-			The higher the number of objects the smaller the overhead
-			of tracking slabs.
-			For more information see Documentation/vm/slub.txt.
-
-	slub_min_order=	[MM, SLUB]
-			Determines the mininum page order for slabs. Must be
-			lower than slub_max_order
-			For more information see Documentation/vm/slub.txt.
-
-	slub_nomerge	[MM, SLUB]
-			Disable merging of slabs of similar size. May be
-			necessary if there is some reason to distinguish
-			allocs to different slabs.
-			For more information see Documentation/vm/slub.txt.
-
 	smart2=		[HW]
 			Format: <io1>[,<io2>[,...,<io8>]]
 

trunk/Documentation/powerpc/booting-without-of.txt

@@ -1,69 +1,14 @@
            Booting the Linux/ppc kernel without Open Firmware
            --------------------------------------------------
 
+
 (c) 2005 Benjamin Herrenschmidt <benh at kernel.crashing.org>,
     IBM Corp.
 (c) 2005 Becky Bruce <becky.bruce at freescale.com>,
     Freescale Semiconductor, FSL SOC and 32-bit additions
 (c) 2006 MontaVista Software, Inc.
     Flash chip node definition
 
-Table of Contents
-=================
-
-  I - Introduction
-    1) Entry point for arch/powerpc
-    2) Board support
-
-  II - The DT block format
-    1) Header
-    2) Device tree generalities
-    3) Device tree "structure" block
-    4) Device tree "strings" block
-
-  III - Required content of the device tree
-    1) Note about cells and address representation
-    2) Note about "compatible" properties
-    3) Note about "name" properties
-    4) Note about node and property names and character set
-    5) Required nodes and properties
-      a) The root node
-      b) The /cpus node
-      c) The /cpus/* nodes
-      d) the /memory node(s)
-      e) The /chosen node
-      f) the /soc<SOCname> node
-
-  IV - "dtc", the device tree compiler
-
-  V - Recommendations for a bootloader
-
-  VI - System-on-a-chip devices and nodes
-    1) Defining child nodes of an SOC
-    2) Representing devices without a current OF specification
-      a) MDIO IO device
-      c) PHY nodes
-      b) Gianfar-compatible ethernet nodes
-      d) Interrupt controllers
-      e) I2C
-      f) Freescale SOC USB controllers
-      g) Freescale SOC SEC Security Engines
-      h) Board Control and Status (BCSR)
-      i) Freescale QUICC Engine module (QE)
-      g) Flash chip nodes
-
-  VII - Specifying interrupt information for devices
-    1) interrupts property
-    2) interrupt-parent property
-    3) OpenPIC Interrupt Controllers
-    4) ISA Interrupt Controllers
-
-  Appendix A - Sample SOC node for MPC8540
-
-
-Revision Information
-====================
-
    May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
 
    May 19, 2005: Rev 0.2 - Add chapter III and bits & pieces here or
@@ -1742,7 +1687,7 @@ platforms are moved over to use the flattened-device-tree model.
 		};
 	};
 
-    j) Flash chip nodes
+    g) Flash chip nodes
 
     Flash chips (Memory Technology Devices) are often used for solid state
     file systems on embedded devices.

trunk/Documentation/sound/alsa/ALSA-Configuration.txt

@@ -917,7 +917,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
 	  ref		Reference board, base config
 	  m2-2		Some Gateway MX series laptops
 	  m6		Some Gateway NX series laptops
-	  pa6		Gateway NX860 series
 
 	STAC9227/9228/9229/927x
 	  ref		Reference board