---

yaml
---
r: 252386
b: refs/heads/master
c: 76b2ab7
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 586893ebc42943008010b4c210cfc9167df615e5
+refs/heads/master: 76b2ab76a4492f8f43c511857181f8421901ce3f

trunk/.gitignore

@@ -57,6 +57,7 @@ modules.builtin
 include/config
 include/linux/version.h
 include/generated
+arch/*/include/generated
 
 # stgit generated dirs
 patches-*

trunk/Documentation/DocBook/Makefile

@@ -73,7 +73,7 @@ installmandocs: mandocs
 ###
 #External programs used
 KERNELDOC = $(srctree)/scripts/kernel-doc
-DOCPROC   = $(objtree)/scripts/basic/docproc
+DOCPROC   = $(objtree)/scripts/docproc
 
 XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl
 XMLTOFLAGS += --skip-validation

trunk/Documentation/arm/Booting

@@ -65,19 +65,13 @@ looks at the connected hardware is beyond the scope of this document.
 The boot loader must ultimately be able to provide a MACH_TYPE_xxx
 value to the kernel. (see linux/arch/arm/tools/mach-types).
 
-4. Setup boot data
-------------------
+
+4. Setup the kernel tagged list
+-------------------------------
 
 Existing boot loaders:		OPTIONAL, HIGHLY RECOMMENDED
 New boot loaders:		MANDATORY
 
-The boot loader must provide either a tagged list or a dtb image for
-passing configuration data to the kernel.  The physical address of the
-boot data is passed to the kernel in register r2.
-
-4a. Setup the kernel tagged list
---------------------------------
-
 The boot loader must create and initialise the kernel tagged list.
 A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE.
 The ATAG_CORE tag may or may not be empty.  An empty ATAG_CORE tag
@@ -107,24 +101,6 @@ The tagged list must be placed in a region of memory where neither
 the kernel decompressor nor initrd 'bootp' program will overwrite
 it.  The recommended placement is in the first 16KiB of RAM.
 
-4b. Setup the device tree
--------------------------
-
-The boot loader must load a device tree image (dtb) into system ram
-at a 64bit aligned address and initialize it with the boot data.  The
-dtb format is documented in Documentation/devicetree/booting-without-of.txt.
-The kernel will look for the dtb magic value of 0xd00dfeed at the dtb
-physical address to determine if a dtb has been passed instead of a
-tagged list.
-
-The boot loader must pass at a minimum the size and location of the
-system memory, and the root filesystem location.  The dtb must be
-placed in a region of memory where the kernel decompressor will not
-overwrite it.  The recommended placement is in the first 16KiB of RAM
-with the caveat that it may not be located at physical address 0 since
-the kernel interprets a value of 0 in r2 to mean neither a tagged list
-nor a dtb were passed.
-
 5. Calling the kernel image
 ---------------------------
 
@@ -149,8 +125,7 @@ In either case, the following conditions must be met:
 - CPU register settings
   r0 = 0,
   r1 = machine type number discovered in (3) above.
-  r2 = physical address of tagged list in system RAM, or
-       physical address of device tree block (dtb) in system RAM
+  r2 = physical address of tagged list in system RAM.
 
 - CPU mode
   All forms of interrupts must be disabled (IRQs and FIQs)

trunk/Documentation/arm/Samsung/Overview.txt

@@ -14,6 +14,7 @@ Introduction
   - S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list
   - S3C64XX: S3C6400 and S3C6410
   - S5P6440
+  - S5P6442
   - S5PC100
   - S5PC110 / S5PV210
 
@@ -35,6 +36,7 @@ Configuration
   unifying all the SoCs into one kernel.
 
   s5p6440_defconfig - S5P6440 specific default configuration
+  s5p6442_defconfig - S5P6442 specific default configuration
   s5pc100_defconfig - S5PC100 specific default configuration
   s5pc110_defconfig - S5PC110 specific default configuration
   s5pv210_defconfig - S5PV210 specific default configuration

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

@@ -12,9 +12,8 @@ Table of Contents
 =================
 
   I - Introduction
-    1) Entry point for arch/arm
-    2) Entry point for arch/powerpc
-    3) Entry point for arch/x86
+    1) Entry point for arch/powerpc
+    2) Entry point for arch/x86
 
   II - The DT block format
     1) Header
@@ -149,46 +148,7 @@ upgrades without significantly impacting the kernel code or cluttering
 it with special cases.
 
 
-1) Entry point for arch/arm
----------------------------
-
-   There is one single entry point to the kernel, at the start
-   of the kernel image. That entry point supports two calling
-   conventions.  A summary of the interface is described here.  A full
-   description of the boot requirements is documented in
-   Documentation/arm/Booting
-
-        a) ATAGS interface.  Minimal information is passed from firmware
-        to the kernel with a tagged list of predefined parameters.
-
-                r0 : 0
-
-                r1 : Machine type number
-
-                r2 : Physical address of tagged list in system RAM
-
-        b) Entry with a flattened device-tree block.  Firmware loads the
-        physical address of the flattened device tree block (dtb) into r2,
-        r1 is not used, but it is considered good practise to use a valid
-        machine number as described in Documentation/arm/Booting.
-
-                r0 : 0
-
-                r1 : Valid machine type number.  When using a device tree,
-                a single machine type number will often be assigned to
-                represent a class or family of SoCs.
-
-                r2 : physical pointer to the device-tree block
-                (defined in chapter II) in RAM.  Device tree can be located
-                anywhere in system RAM, but it should be aligned on a 64 bit
-                boundary.
-
-   The kernel will differentiate between ATAGS and device tree booting by
-   reading the memory pointed to by r2 and looking for either the flattened
-   device tree block magic value (0xd00dfeed) or the ATAG_CORE value at
-   offset 0x4 from r2 (0x54410001).
-
-2) Entry point for arch/powerpc
+1) Entry point for arch/powerpc
 -------------------------------
 
    There is one single entry point to the kernel, at the start
@@ -266,7 +226,7 @@ it with special cases.
   cannot support both configurations with Book E and configurations
   with classic Powerpc architectures.
 
-3) Entry point for arch/x86
+2) Entry point for arch/x86
 -------------------------------
 
   There is one single 32bit entry point to the kernel at code32_start,

trunk/Documentation/filesystems/ubifs.txt

@@ -115,28 +115,8 @@ ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs
 Module Parameters for Debugging
 ===============================
 
-When UBIFS has been compiled with debugging enabled, there are 3 module
+When UBIFS has been compiled with debugging enabled, there are 2 module
 parameters that are available to control aspects of testing and debugging.
-The parameters are unsigned integers where each bit controls an option.
-The parameters are:
-
-debug_msgs	Selects which debug messages to display, as follows:
-
-		Message Type				Flag value
-
-		General messages			1
-		Journal messages			2
-		Mount messages				4
-		Commit messages				8
-		LEB search messages			16
-		Budgeting messages			32
-		Garbage collection messages		64
-		Tree Node Cache (TNC) messages		128
-		LEB properties (lprops) messages	256
-		Input/output messages			512
-		Log messages				1024
-		Scan messages				2048
-		Recovery messages			4096
 
 debug_chks	Selects extra checks that UBIFS can do while running:
 
@@ -154,11 +134,9 @@ debug_tsts	Selects a mode of testing, as follows:
 
 		Test mode				Flag value
 
-		Force in-the-gaps method		2
 		Failure mode for recovery testing	4
 
-For example, set debug_msgs to 5 to display General messages and Mount
-messages.
+For example, set debug_chks to 3 to enable general and TNC checks.
 
 
 References

trunk/Documentation/i2c/busses/i2c-i801

@@ -19,6 +19,7 @@ Supported adapters:
   * Intel 6 Series (PCH)
   * Intel Patsburg (PCH)
   * Intel DH89xxCC (PCH)
+  * Intel Panther Point (PCH)
    Datasheets: Publicly available at the Intel website
 
 On Intel Patsburg and later chipsets, both the normal host SMBus controller

trunk/Documentation/i2c/writing-clients

@@ -38,7 +38,7 @@ static struct i2c_driver foo_driver = {
 		.name	= "foo",
 	},
 
-	.id_table	= foo_ids,
+	.id_table	= foo_idtable,
 	.probe		= foo_probe,
 	.remove		= foo_remove,
 	/* if device autodetection is needed: */