249 files changed, 7113 insertions, 3619 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 8afe64fb2009..0f3e8bbab8d7 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -2,7 +2,7 @@
 This is a brief list of all the files in ./linux/Documentation and what
 they contain. If you add a documentation file, please list it here in
 alphabetical order as well, or risk being hunted down like a rabid dog.
-Please try and keep the descriptions small enough to fit on one line.
+Please keep the descriptions small enough to fit on one line.
                                                         Thanks -- Paul G.
 Following translations are available on the WWW:
@@ -20,24 +20,33 @@ BUG-HUNTING
 Changes
        - list of changes that break older software packages.
 CodingStyle
-        - how the boss likes the C code in the kernel to look.
+        - how the maintainers expect the C code in the kernel to look.
-development-process/
-        - An extended tutorial on how to work with the kernel development
-          process.
 DMA-API.txt
        - DMA API, pci_ API & extensions for non-consistent memory machines.
+DMA-API-HOWTO.txt
+        - Dynamic DMA mapping Guide
 DMA-ISA-LPC.txt
        - How to do DMA with ISA (and LPC) devices.
+DMA-attributes.txt
+        - listing of the various possible attributes a DMA region can have
 DocBook/
        - directory with DocBook templates etc. for kernel documentation.
+EDID/
+        - directory with info on customizing EDID for broken gfx/displays.
 HOWTO
        - the process and procedures of how to do Linux kernel development.
 IPMI.txt
        - info on Linux Intelligent Platform Management Interface (IPMI) Driver.
 IRQ-affinity.txt
        - how to select which CPU(s) handle which interrupt events on SMP.
+IRQ-domain.txt
+        - info on inerrupt numbering and setting up IRQ domains.
 IRQ.txt
        - description of what an IRQ is.
+Intel-IOMMU.txt
+        - basic info on the Intel IOMMU virtualization support.
+Makefile
+        - some files in Documentation dir are actually sample code to build
 ManagementStyle
        - how to (attempt to) manage kernel hackers.
 RCU/
@@ -66,10 +75,16 @@ applying-patches.txt
        - description of various trees and how to apply their patches.
 arm/
        - directory with info about Linux on the ARM architecture.
+arm64/
+        - directory with info about Linux on the 64 bit ARM architecture.
 atomic_ops.txt
        - semantics and behavior of atomic and bitmask operations.
 auxdisplay/
        - misc. LCD driver documentation (cfag12864b, ks0108).
+backlight/
+        - directory with info on controlling backlights in flat panel displays
+bad_memory.txt
+        - how to use kernel parameters to exclude bad RAM regions.
 basic_profiling.txt
        - basic instructions for those who wants to profile Linux kernel.
 binfmt_misc.txt
@@ -80,8 +95,14 @@ block/
        - info on the Block I/O (BIO) layer.
 blockdev/
        - info on block devices & drivers
+braille-console.txt
+        - info on how to use serial devices for Braille support.
+bt8xxgpio.txt
+        - info on how to modify a bt8xx video card for GPIO usage.
 btmrvl.txt
        - info on Marvell Bluetooth driver usage.
+bus-devices/
+        - directory with info on TI GPMC (General Purpose Memory Controller)
 bus-virt-phys-mapping.txt
        - how to access I/O mapped memory from within device drivers.
 cachetlb.txt
@@ -90,6 +111,12 @@ cdrom/
        - directory with information on the CD-ROM drivers that Linux has.
 cgroups/
        - cgroups features, including cpusets and memory controller.
+circular-buffers.txt
+        - how to make use of the existing circular buffer infrastructure
+clk.txt
+        - info on the common clock framework
+coccinelle.txt
+        - info on how to get and use the Coccinelle code checking tool.
 connector/
        - docs on the netlink based userspace<->kernel space communication mod.
 console/
@@ -114,24 +141,42 @@ dcdbas.txt
        - information on the Dell Systems Management Base Driver.
 debugging-modules.txt
        - some notes on debugging modules after Linux 2.6.3.
+debugging-via-ohci1394.txt
+        - how to use firewire like a hardware debugger memory reader.
 dell_rbu.txt
        - document demonstrating the use of the Dell Remote BIOS Update driver.
+development-process/
+        - how to work with the mainline kernel development process.
 device-mapper/
        - directory with info on Device Mapper.
 devices.txt
        - plain ASCII listing of all the nodes in /dev/ with major minor #'s.
+devicetree/
+        - directory with info on device tree files used by OF/PowerPC/ARM
+digsig.txt
+        -info on the Digital Signature Verification API
+dma-buf-sharing.txt
+        - the DMA Buffer Sharing API Guide
+dmaengine.txt
+        -the DMA Engine API Guide
 dontdiff
        - file containing a list of files that should never be diff'ed.
 driver-model/
        - directory with info about Linux driver model.
 dvb/
        - info on Linux Digital Video Broadcast (DVB) subsystem.
+dynamic-debug-howto.txt
+        - how to use the dynamic debug (dyndbg) feature.
 early-userspace/
        - info about initramfs, klibc, and userspace early during boot.
 edac.txt
        - information on EDAC - Error Detection And Correction
 eisa.txt
        - info on EISA bus support.
+email-clients.txt
+        - info on how to use e-mail to send un-mangled (git) patches.
+extcon/
+        - directory with porting guide for Android kernel switch driver.
 fault-injection/
        - dir with docs about the fault injection capabilities infrastructure.
 fb/
@@ -140,12 +185,22 @@ filesystems/
        - info on the vfs and the various filesystems that Linux supports.
 firmware_class/
        - request_firmware() hotplug interface info.
+flexible-arrays.txt
+        - how to make use of flexible sized arrays in linux
 frv/
        - Fujitsu FR-V Linux documentation.
+futex-requeue-pi.txt
+        - info on requeueing of tasks from a non-PI futex to a PI futex
+gcov.txt
+        - use of GCC's coverage testing tool "gcov" with the Linux kernel
 gpio.txt
        - overview of GPIO (General Purpose Input/Output) access conventions.
+hid/
+        - directory with information on human interface devices
 highuid.txt
        - notes on the change from 16 bit to 32 bit user/group IDs.
+hwspinlock.txt
+        - hardware spinlock provides hardware assistance for synchronization
 timers/
        - info on the timer related topics
 hw_random.txt
@@ -162,10 +217,14 @@ ia64/
        - directory with info about Linux on Intel 64 bit architecture.
 infiniband/
        - directory with documents concerning Linux InfiniBand support.
+init.txt
+        - what to do when the kernel can't find the 1st process to run.
 initrd.txt
        - how to use the RAM disk as an initial/temporary root filesystem.
 input/
        - info on Linux input device support.
+intel_txt.txt
+        - info on intel Trusted Execution Technology (intel TXT).
 io-mapping.txt
        - description of io_mapping functions in linux/io-mapping.h
 io_ordering.txt
@@ -182,6 +241,8 @@ isdn/
        - directory with info on the Linux ISDN support, and supported cards.
 java.txt
        - info on the in-kernel binary support for Java(tm).
+ja_JP/
+        - directory with Japanese translations of various documents
 kbuild/
        - directory with info about the kernel build process.
 kdump/
@@ -192,6 +253,12 @@ kernel-docs.txt
        - listing of various WWW + books that document kernel internals.
 kernel-parameters.txt
        - summary listing of command line / boot prompt args for the kernel.
+kmemcheck.txt
+        - info on dynamic checker that detects uses of uninitialized memory.
+kmemleak.txt
+        - info on how to make use of the kernel memory leak detection system
+ko_KR/
+        - directory with Korean translations of various documents
 kobject.txt
        - info of the kobject infrastructure of the Linux kernel.
 kprobes.txt
@@ -208,6 +275,8 @@ local_ops.txt
        - semantics and behavior of local atomic operations.
 lockdep-design.txt
        - documentation on the runtime locking correctness validator.
+lockstat.txt
+        - info on collecting statistics on locks (and contention).
 lockup-watchdogs.txt
        - info on soft and hard lockup detectors (aka nmi_watchdog).
 logo.gif
@@ -220,16 +289,26 @@ magic-number.txt
        - list of magic numbers used to mark/protect kernel data structures.
 md.txt
        - info on boot arguments for the multiple devices driver.
+media-framework.txt
+        - info on media framework, its data structures, functions and usage.
 memory-barriers.txt
        - info on Linux kernel memory barriers.
+memory-devices/
+        - directory with info on parts like the Texas Instruments EMIF driver
 memory-hotplug.txt
        - Hotpluggable memory support, how to use and current status.
 memory.txt
        - info on typical Linux memory problems.
 mips/
        - directory with info about Linux on MIPS architecture.
+misc-devices/
+        - directory with info about devices using the misc dev subsystem
 mmc/
        - directory with info about the MMC subsystem
+mn10300/
+        - directory with info about the mn10300 architecture port
+mtd/
+        - directory with info about memory technology devices (flash)
 mono.txt
        - how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
 mutex-design.txt
@@ -240,6 +319,8 @@ netlabel/
        - directory with information on the NetLabel subsystem.
 networking/
        - directory with info on various aspects of networking with Linux.
+nfc/
+        - directory relating info about Near Field Communications support.
 nommu-mmap.txt
        - documentation about no-mmu memory mapping support.
 numastat.txt
@@ -256,26 +337,46 @@ parport-lowlevel.txt
        - description and usage of the low level parallel port functions.
 pcmcia/
        - info on the Linux PCMCIA driver.
+percpu-rw-semaphore.txt
+        - RCU based read-write semaphore optimized for locking for reading
 pi-futex.txt
-        - documentation on lightweight PI-futexes.
+        - documentation on lightweight priority inheritance futexes.
+pinctrl.txt
+        - info on pinctrl subsystem and the PINMUX/PINCONF and drivers
 pnp.txt
        - Linux Plug and Play documentation.
 power/
        - directory with info on Linux PCI power management.
 powerpc/
        - directory with info on using Linux with the PowerPC.
+prctl/
+        - directory with info on the priveledge control subsystem
 preempt-locking.txt
        - info on locking under a preemptive kernel.
 printk-formats.txt
        - how to get printk format specifiers right
+pps/
+        - directory with information on the pulse-per-second support
+ptp/
+        - directory with info on support for IEEE 1588 PTP clocks in Linux.
+pwm.txt
+        - info on the pulse width modulation driver subsystem
 ramoops.txt
        - documentation of the ramoops oops/panic logging module.
+rapidio/
+        - directory with info on RapidIO packet-based fabric interconnect
 rbtree.txt
        - info on what red-black trees are and what they are for.
+remoteproc.txt
+        - info on how to handle remote processor (e.g. AMP) offloads/usage.
+rfkill.txt
+        - info on the radio frequency kill switch subsystem/support.
 robust-futex-ABI.txt
        - documentation of the robust futex ABI.
 robust-futexes.txt
        - a description of what robust futexes are.
+rpmsg.txt
+        - info on the Remote Processor Messaging (rpmsg) Framework
 rt-mutex-design.txt
        - description of the RealTime mutex implementation design.
 rt-mutex.txt
@@ -300,10 +401,10 @@ sgi-visws.txt
        - short blurb on the SGI Visual Workstations.
 sh/
        - directory with info on porting Linux to a new architecture.
+smsc_ece1099.txt
+        -info on the smsc Keyboard Scan Expansion/GPIO Expansion device.
 sound/
        - directory with info on sound card support.
-sparc/
-        - directory with info on using Linux on Sparc architecture.
 sparse.txt
        - info on how to obtain and use the sparse tool for typechecking.
 spi/
@@ -314,6 +415,8 @@ stable_api_nonsense.txt
        - info on why the kernel does not have a stable in-kernel api or abi.
 stable_kernel_rules.txt
        - rules and procedures for the -stable kernel releases.
+static-keys.txt
+        - info on how static keys allow debug code in hotpaths via patching
 svga.txt
        - short guide on selecting video modes at boot via VGA BIOS.
 sysfs-rules.txt
@@ -322,27 +425,53 @@ sysctl/
        - directory with info on the /proc/sys/* files.
 sysrq.txt
        - info on the magic SysRq key.
-telephony/
+target/
-        - directory with info on telephony (e.g. voice over IP) support.
+        - directory with info on generating TCM v4 fabric .ko modules
+thermal/
+        - directory with information on managing thermal issues (CPU/temp)
+trace/
+        - directory with info on tracing technologies within linux
+unaligned-memory-access.txt
+        - info on how to avoid arch breaking unaligned memory access in code.
 unicode.txt
        - info on the Unicode character/font mapping used in Linux.
 unshare.txt
        - description of the Linux unshare system call.
 usb/
        - directory with info regarding the Universal Serial Bus.
+vDSO/
+        - directory with info regarding virtual dynamic shared objects
+vfio.txt
+        - info on Virtual Function I/O used in guest/hypervisor instances.
+vgaarbiter.txt
+        - info on enable/disable the legacy decoding on different VGA devices
 video-output.txt
        - sysfs class driver interface to enable/disable a video output device.
 video4linux/
        - directory with info regarding video/TV/radio cards and linux.
+virtual/
+        - directory with information on the various linux virtualizations.
 vm/
        - directory with info on the Linux vm code.
+vme_api.txt
+        - file relating info on the VME bus API in linux
 volatile-considered-harmful.txt
        - Why the "volatile" type class should not be used
 w1/
        - directory with documents regarding the 1-wire (w1) subsystem.
 watchdog/
        - how to auto-reboot Linux if it has "fallen and can't get up". ;-)
+wimax/
+        - directory with info about Intel Wireless Wimax Connections
+workqueue.txt
+        - information on the Concurrency Managed Workqueue implementation
 x86/x86_64/
        - directory with info on Linux support for AMD x86-64 (Hammer) machines.
+xtensa/
+        - directory with documents relating to arch/xtensa port/implementation
+xz.txt
+        - how to make use of the XZ data compression within linux kernel
+zh_CN/
+        - directory with Chinese translations of various documents
 zorro.txt
        - info on writing drivers for Zorro bus devices found on Amigas.
diff --git a/Documentation/ABI/stable/sysfs-class-tpm b/Documentation/ABI/stable/sysfs-class-tpm
new file mode 100644
index 000000000000..a60b45e2493b
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-class-tpm
@@ -0,0 +1,185 @@
+What:           /sys/class/misc/tpmX/device/
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        tpmdd-devel@lists.sf.net
+Description:    The device/ directory under a specific TPM instance exposes
+                the properties of that TPM chip
+What:           /sys/class/misc/tpmX/device/active
+Date:           April 2006
+KernelVersion:  2.6.17
+Contact:        tpmdd-devel@lists.sf.net
+Description:    The "active" property prints a '1' if the TPM chip is accepting
+                commands. An inactive TPM chip still contains all the state of
+                an active chip (Storage Root Key, NVRAM, etc), and can be
+                visible to the OS, but will only accept a restricted set of
+                commands. See the TPM Main Specification part 2, Structures,
+                section 17 for more information on which commands are
+                available.
+What:           /sys/class/misc/tpmX/device/cancel
+Date:           June 2005
+KernelVersion:  2.6.13
+Contact:        tpmdd-devel@lists.sf.net
+Description:    The "cancel" property allows you to cancel the currently
+                pending TPM command. Writing any value to cancel will call the
+                TPM vendor specific cancel operation.
+What:           /sys/class/misc/tpmX/device/caps
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        tpmdd-devel@lists.sf.net
+Description:    The "caps" property contains TPM manufacturer and version info.
+                Example output:
+                Manufacturer: 0x53544d20
+                TCG version: 1.2
+                Firmware version: 8.16
+                Manufacturer is a hex dump of the 4 byte manufacturer info
+                space in a TPM. TCG version shows the TCG TPM spec level that
+                the chip supports. Firmware version is that of the chip and
+                is manufacturer specific.
+What:           /sys/class/misc/tpmX/device/durations
+Date:           March 2011
+KernelVersion:  3.1
+Contact:        tpmdd-devel@lists.sf.net
+Description:    The "durations" property shows the 3 vendor-specific values
+                used to wait for a short, medium and long TPM command. All
+                TPM commands are categorized as short, medium or long in
+                execution time, so that the driver doesn't have to wait
+                any longer than necessary before starting to poll for a
+                result.
+                Example output:
+                3015000 4508000 180995000 [original]
+                Here the short, medium and long durations are displayed in
+                usecs. "[original]" indicates that the values are displayed
+                unmodified from when they were queried from the chip.
+                Durations can be modified in the case where a buggy chip
+                reports them in msec instead of usec and they need to be
+                scaled to be displayed in usecs. In this case "[adjusted]"
+                will be displayed in place of "[original]".
+What:           /sys/class/misc/tpmX/device/enabled
+Date:           April 2006
+KernelVersion:  2.6.17
+Contact:        tpmdd-devel@lists.sf.net
+Description:    The "enabled" property prints a '1' if the TPM chip is enabled,
+                meaning that it should be visible to the OS. This property
+                may be visible but produce a '0' after some operation that
+                disables the TPM.
+What:           /sys/class/misc/tpmX/device/owned
+Date:           April 2006
+KernelVersion:  2.6.17
+Contact:        tpmdd-devel@lists.sf.net
+Description:    The "owned" property produces a '1' if the TPM_TakeOwnership
+                ordinal has been executed successfully in the chip. A '0'
+                indicates that ownership hasn't been taken.
+What:           /sys/class/misc/tpmX/device/pcrs
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        tpmdd-devel@lists.sf.net
+Description:    The "pcrs" property will dump the current value of all Platform
+                Configuration Registers in the TPM. Note that since these
+                values may be constantly changing, the output is only valid
+                for a snapshot in time.
+                Example output:
+                PCR-00: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
+                PCR-01: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
+                PCR-02: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
+                PCR-03: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
+                PCR-04: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
+                ...
+                The number of PCRs and hex bytes needed to represent a PCR
+                value will vary depending on TPM chip version. For TPM 1.1 and
+                1.2 chips, PCRs represent SHA-1 hashes, which are 20 bytes
+                long. Use the "caps" property to determine TPM version.
+What:           /sys/class/misc/tpmX/device/pubek
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        tpmdd-devel@lists.sf.net
+Description:    The "pubek" property will return the TPM's public endorsement
+                key if possible. If the TPM has had ownership established and
+                is version 1.2, the pubek will not be available without the
+                owner's authorization. Since the TPM driver doesn't store any
+                secrets, it can't authorize its own request for the pubek,
+                making it unaccessible. The public endorsement key is gener-
+                ated at TPM menufacture time and exists for the life of the
+                chip.
+                Example output:
+                Algorithm: 00 00 00 01
+                Encscheme: 00 03
+                Sigscheme: 00 01
+                Parameters: 00 00 08 00 00 00 00 02 00 00 00 00
+                Modulus length: 256
+                Modulus:
+                B4 76 41 82 C9 20 2C 10 18 40 BC 8B E5 44 4C 6C
+                3A B2 92 0C A4 9B 2A 83 EB 5C 12 85 04 48 A0 B6
+                1E E4 81 84 CE B2 F2 45 1C F0 85 99 61 02 4D EB
+                86 C4 F7 F3 29 60 52 93 6B B2 E5 AB 8B A9 09 E3
+                D7 0E 7D CA 41 BF 43 07 65 86 3C 8C 13 7A D0 8B
+                82 5E 96 0B F8 1F 5F 34 06 DA A2 52 C1 A9 D5 26
+                0F F4 04 4B D9 3F 2D F2 AC 2F 74 64 1F 8B CD 3E
+                1E 30 38 6C 70 63 69 AB E2 50 DF 49 05 2E E1 8D
+                6F 78 44 DA 57 43 69 EE 76 6C 38 8A E9 8E A3 F0
+                A7 1F 3C A8 D0 12 15 3E CA 0E BD FA 24 CD 33 C6
+                47 AE A4 18 83 8E 22 39 75 93 86 E6 FD 66 48 B6
+                10 AD 94 14 65 F9 6A 17 78 BD 16 53 84 30 BF 70
+                E0 DC 65 FD 3C C6 B0 1E BF B9 C1 B5 6C EF B1 3A
+                F8 28 05 83 62 26 11 DC B4 6B 5A 97 FF 32 26 B6
+                F7 02 71 CF 15 AE 16 DD D1 C1 8E A8 CF 9B 50 7B
+                C3 91 FF 44 1E CF 7C 39 FE 17 77 21 20 BD CE 9B
+                Possible values:
+                Algorithm:      TPM_ALG_RSA                     (1)
+                Encscheme:      TPM_ES_RSAESPKCSv15             (2)
+                                TPM_ES_RSAESOAEP_SHA1_MGF1      (3)
+                Sigscheme:      TPM_SS_NONE                     (1)
+                Parameters, a byte string of 3 u32 values:
+                        Key Length (bits):      00 00 08 00     (2048)
+                        Num primes:             00 00 00 02     (2)
+                        Exponent Size:          00 00 00 00     (0 means the
+                                                                 default exp)
+                Modulus Length: 256 (bytes)
+                Modulus:        The 256 byte Endorsement Key modulus
+What:           /sys/class/misc/tpmX/device/temp_deactivated
+Date:           April 2006
+KernelVersion:  2.6.17
+Contact:        tpmdd-devel@lists.sf.net
+Description:    The "temp_deactivated" property returns a '1' if the chip has
+                been temporarily dectivated, usually until the next power
+                cycle. Whether a warm boot (reboot) will clear a TPM chip
+                from a temp_deactivated state is platform specific.
+What:           /sys/class/misc/tpmX/device/timeouts
+Date:           March 2011
+KernelVersion:  3.1
+Contact:        tpmdd-devel@lists.sf.net
+Description:    The "timeouts" property shows the 4 vendor-specific values
+                for the TPM's interface spec timeouts. The use of these
+                timeouts is defined by the TPM interface spec that the chip
+                conforms to.
+                Example output:
+                750000 750000 750000 750000 [original]
+                The four timeout values are shown in usecs, with a trailing
+                "[original]" or "[adjusted]" depending on whether the values
+                were scaled by the driver to be reported in usec from msecs.
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index ec0a38ef3145..f1c5cc9d17a8 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -18,17 +18,21 @@ Description:
                rule format: action [condition ...]
                action: measure | dont_measure | appraise | dont_appraise | audit
-                condition:= base | lsm
+                condition:= base | lsm  [option]
-                        base:   [[func=] [mask=] [fsmagic=] [uid=] [fowner]]
+                        base:   [[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
+                                 [fowner]]
                        lsm:    [[subj_user=] [subj_role=] [subj_type=]
                                 [obj_user=] [obj_role=] [obj_type=]]
+                        option: [[appraise_type=]]
-                base:   func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK][MODULE_CHECK]
+                base:   func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
                        mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
                        fsmagic:= hex value
+                        fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
                        uid:= decimal value
                        fowner:=decimal value
                lsm:    are LSM specific
+                option: appraise_type:= [imasig]
                default policy:
                        # PROC_SUPER_MAGIC
diff --git a/Documentation/ABI/testing/pstore b/Documentation/ABI/testing/pstore
index ff1df4e3b059..5fca9f5e10a3 100644
--- a/Documentation/ABI/testing/pstore
+++ b/Documentation/ABI/testing/pstore
@@ -1,4 +1,4 @@
-Where:          /dev/pstore/...
+Where:          /sys/fs/pstore/... (or /dev/pstore/...)
 Date:           March 2011
 Kernel Version: 2.6.39
 Contact:        tony.luck@intel.com
@@ -11,9 +11,9 @@ Description:	Generic interface to platform dependent persistent storage.
                of the console log is captured, but other interesting
                data can also be saved.
-                # mount -t pstore -o kmsg_bytes=8000 - /dev/pstore
+                # mount -t pstore -o kmsg_bytes=8000 - /sys/fs/pstore
-                $ ls -l /dev/pstore
+                $ ls -l /sys/fs/pstore/
                total 0
                -r--r--r-- 1 root root 7896 Nov 30 15:38 dmesg-erst-1
@@ -27,9 +27,9 @@ Description:	Generic interface to platform dependent persistent storage.
                the file will signal to the underlying persistent storage
                device that it can reclaim the space for later re-use.
-                $ rm /dev/pstore/dmesg-erst-1
+                $ rm /sys/fs/pstore/dmesg-erst-1
-                The expectation is that all files in /dev/pstore
+                The expectation is that all files in /sys/fs/pstore/
                will be saved elsewhere and erased from persistent store
                soon after boot to free up space ready for the next
                catastrophe.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
new file mode 100644
index 000000000000..0adeb524c0d4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -0,0 +1,62 @@
+What:           /sys/devices/cpu/events/
+                /sys/devices/cpu/events/branch-misses
+                /sys/devices/cpu/events/cache-references
+                /sys/devices/cpu/events/cache-misses
+                /sys/devices/cpu/events/stalled-cycles-frontend
+                /sys/devices/cpu/events/branch-instructions
+                /sys/devices/cpu/events/stalled-cycles-backend
+                /sys/devices/cpu/events/instructions
+                /sys/devices/cpu/events/cpu-cycles
+Date:           2013/01/08
+Contact:        Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:    Generic performance monitoring events
+                A collection of performance monitoring events that may be
+                supported by many/most CPUs. These events can be monitored
+                using the 'perf(1)' tool.
+                The contents of each file would look like:
+                        event=0xNNNN
+                where 'N' is a hex digit and the number '0xNNNN' shows the
+                "raw code" for the perf event identified by the file's
+                "basename".
+What:           /sys/devices/cpu/events/PM_LD_MISS_L1
+                /sys/devices/cpu/events/PM_LD_REF_L1
+                /sys/devices/cpu/events/PM_CYC
+                /sys/devices/cpu/events/PM_BRU_FIN
+                /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
+                /sys/devices/cpu/events/PM_BRU_MPRED
+                /sys/devices/cpu/events/PM_INST_CMPL
+                /sys/devices/cpu/events/PM_CMPLU_STALL
+Date:           2013/01/08
+Contact:        Linux kernel mailing list <linux-kernel@vger.kernel.org>
+                Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
+Description:    POWER-systems specific performance monitoring events
+                A collection of performance monitoring events that may be
+                supported by the POWER CPU. These events can be monitored
+                using the 'perf(1)' tool.
+                These events may not be supported by other CPUs.
+                The contents of each file would look like:
+                        event=0xNNNN
+                where 'N' is a hex digit and the number '0xNNNN' shows the
+                "raw code" for the perf event identified by the file's
+                "basename".
+                Further, multiple terms like 'event=0xNNNN' can be specified
+                and separated with comma. All available terms are defined in
+                the /sys/bus/event_source/devices/<dev>/format file.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-mpu6050 b/Documentation/ABI/testing/sysfs-bus-iio-mpu6050
new file mode 100644
index 000000000000..cb53737aacbf
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-mpu6050
@@ -0,0 +1,13 @@
+What:           /sys/bus/iio/devices/iio:deviceX/in_gyro_matrix
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_matrix
+What:           /sys/bus/iio/devices/iio:deviceX/in_magn_matrix
+KernelVersion:  3.4.0
+Contact:        linux-iio@vger.kernel.org
+Description:
+                This is mounting matrix for motion sensors. Mounting matrix
+                is a 3x3 unitary matrix. A typical mounting matrix would look like
+                [0, 1, 0; 1, 0, 0; 0, 0, -1]. Using this information, it would be
+                easy to tell the relative positions among sensors as well as their
+                positions relative to the board that holds these sensors. Identity matrix
+                [1, 0, 0; 0, 1, 0; 0, 0, 1] means sensor chip and device are perfectly
+                aligned with each other. All axes are exactly the same.
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index b6fbe514a869..c8baaf53594a 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -227,3 +227,12 @@ Contact:	Lan Tianyu <tianyu.lan@intel.com>
 Description:
                The /sys/bus/usb/devices/.../(hub interface)/portX
                is usb port device's sysfs directory.
+What:           /sys/bus/usb/devices/.../(hub interface)/portX/connect_type
+Date:           January 2013
+Contact:        Lan Tianyu <tianyu.lan@intel.com>
+Description:
+                Some platforms provide usb port connect types through ACPI.
+                This attribute is to expose these information to user space.
+                The file will read "hotplug", "wired" and "not used" if the
+                information is available, and "unknown" otherwise.
diff --git a/Documentation/ABI/testing/sysfs-class-bdi b/Documentation/ABI/testing/sysfs-class-bdi
index 5f500977b42f..d773d5697cf5 100644
--- a/Documentation/ABI/testing/sysfs-class-bdi
+++ b/Documentation/ABI/testing/sysfs-class-bdi
@@ -48,3 +48,8 @@ max_ratio (read-write)
        most of the write-back cache.  For example in case of an NFS
        mount that is prone to get stuck, or a FUSE mount which cannot
        be trusted to play fair.
+stable_pages_required (read-only)
+        If set, the backing device requires that all pages comprising a write
+        request must not be changed until writeout is complete.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_resources_D0 b/Documentation/ABI/testing/sysfs-devices-power_resources_D0
new file mode 100644
index 000000000000..73b77a6be196
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_resources_D0
@@ -0,0 +1,13 @@
+What:           /sys/devices/.../power_resources_D0/
+Date:           January 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../power_resources_D0/ directory is only
+                present for device objects representing ACPI device nodes that
+                use ACPI power resources for power management.
+                If present, it contains symbolic links to device directories
+                representing ACPI power resources that need to be turned on for
+                the given device node to be in ACPI power state D0.  The names
+                of the links are the same as the names of the directories they
+                point to.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_resources_D1 b/Documentation/ABI/testing/sysfs-devices-power_resources_D1
new file mode 100644
index 000000000000..30c20703fb8c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_resources_D1
@@ -0,0 +1,14 @@
+What:           /sys/devices/.../power_resources_D1/
+Date:           January 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../power_resources_D1/ directory is only
+                present for device objects representing ACPI device nodes that
+                use ACPI power resources for power management and support ACPI
+                power state D1.
+                If present, it contains symbolic links to device directories
+                representing ACPI power resources that need to be turned on for
+                the given device node to be in ACPI power state D1.  The names
+                of the links are the same as the names of the directories they
+                point to.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_resources_D2 b/Documentation/ABI/testing/sysfs-devices-power_resources_D2
new file mode 100644
index 000000000000..fd9d84b421e1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_resources_D2
@@ -0,0 +1,14 @@
+What:           /sys/devices/.../power_resources_D2/
+Date:           January 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../power_resources_D2/ directory is only
+                present for device objects representing ACPI device nodes that
+                use ACPI power resources for power management and support ACPI
+                power state D2.
+                If present, it contains symbolic links to device directories
+                representing ACPI power resources that need to be turned on for
+                the given device node to be in ACPI power state D2.  The names
+                of the links are the same as the names of the directories they
+                point to.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_resources_D3hot b/Documentation/ABI/testing/sysfs-devices-power_resources_D3hot
new file mode 100644
index 000000000000..3df32c20addf
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_resources_D3hot
@@ -0,0 +1,14 @@
+What:           /sys/devices/.../power_resources_D3hot/
+Date:           January 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../power_resources_D3hot/ directory is only
+                present for device objects representing ACPI device nodes that
+                use ACPI power resources for power management and support ACPI
+                power state D3hot.
+                If present, it contains symbolic links to device directories
+                representing ACPI power resources that need to be turned on for
+                the given device node to be in ACPI power state D3hot.  The
+                names of the links are the same as the names of the directories
+                they point to.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_state b/Documentation/ABI/testing/sysfs-devices-power_state
new file mode 100644
index 000000000000..7ad9546748f0
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_state
@@ -0,0 +1,20 @@
+What:           /sys/devices/.../power_state
+Date:           January 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../power_state attribute is only present for
+                device objects representing ACPI device nodes that provide power
+                management methods.
+                If present, it contains a string representing the current ACPI
+                power state of the given device node.  Its possible values,
+                "D0", "D1", "D2", "D3hot", and "D3cold", reflect the power state
+                names defined by the ACPI specification (ACPI 4 and above).
+                If the device node uses shared ACPI power resources, this state
+                determines a list of power resources required not to be turned
+                off.  However, some power resources needed by the device node in
+                higher-power (lower-number) states may also be ON because of
+                some other devices using them at the moment.
+                This attribute is read-only.
diff --git a/Documentation/ABI/testing/sysfs-devices-real_power_state b/Documentation/ABI/testing/sysfs-devices-real_power_state
new file mode 100644
index 000000000000..8b3527c82a7d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-real_power_state
@@ -0,0 +1,23 @@
+What:           /sys/devices/.../real_power_state
+Date:           January 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../real_power_state attribute is only present
+                for device objects representing ACPI device nodes that provide
+                power management methods and use ACPI power resources for power
+                management.
+                If present, it contains a string representing the real ACPI
+                power state of the given device node as returned by the _PSC
+                control method or inferred from the configuration of power
+                resources.  Its possible values, "D0", "D1", "D2", "D3hot", and
+                "D3cold", reflect the power state names defined by the ACPI
+                specification (ACPI 4 and above).
+                In some situations the value of this attribute may be different
+                from the value of the /sys/devices/.../power_state attribute for
+                the same device object.  If that happens, some shared power
+                resources used by the device node are only ON because of some
+                other devices using them at the moment.
+                This attribute is read-only.
diff --git a/Documentation/ABI/testing/sysfs-devices-resource_in_use b/Documentation/ABI/testing/sysfs-devices-resource_in_use
new file mode 100644
index 000000000000..b4a3bc5922a3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-resource_in_use
@@ -0,0 +1,12 @@
+What:           /sys/devices/.../resource_in_use
+Date:           January 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../resource_in_use attribute is only present
+                for device objects representing ACPI power resources.
+                If present, it contains a number (0 or 1) representing the
+                current status of the given power resource (0 means that the
+                resource is not in use and therefore it has been turned off).
+                This attribute is read-only.
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 6943133afcb8..9c978dcae07d 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -67,20 +67,6 @@ Description:	Discover NUMA node a CPU belongs to
                /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
-What:           /sys/devices/system/cpu/cpu#/node
-Date:           October 2009
-Contact:        Linux memory management mailing list <linux-mm@kvack.org>
-Description:    Discover NUMA node a CPU belongs to
-                When CONFIG_NUMA is enabled, a symbolic link that points
-                to the corresponding NUMA node directory.
-                For example, the following symlink is created for cpu42
-                in NUMA node 2:
-                /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
 What:           /sys/devices/system/cpu/cpu#/topology/core_id
                /sys/devices/system/cpu/cpu#/topology/core_siblings
                /sys/devices/system/cpu/cpu#/topology/core_siblings_list
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-srws1 b/Documentation/ABI/testing/sysfs-driver-hid-srws1
new file mode 100644
index 000000000000..d0eba70c7d40
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-srws1
@@ -0,0 +1,21 @@
+What:           /sys/class/leds/SRWS1::<serial>::RPM1
+What:           /sys/class/leds/SRWS1::<serial>::RPM2
+What:           /sys/class/leds/SRWS1::<serial>::RPM3
+What:           /sys/class/leds/SRWS1::<serial>::RPM4
+What:           /sys/class/leds/SRWS1::<serial>::RPM5
+What:           /sys/class/leds/SRWS1::<serial>::RPM6
+What:           /sys/class/leds/SRWS1::<serial>::RPM7
+What:           /sys/class/leds/SRWS1::<serial>::RPM8
+What:           /sys/class/leds/SRWS1::<serial>::RPM9
+What:           /sys/class/leds/SRWS1::<serial>::RPM10
+What:           /sys/class/leds/SRWS1::<serial>::RPM11
+What:           /sys/class/leds/SRWS1::<serial>::RPM12
+What:           /sys/class/leds/SRWS1::<serial>::RPM13
+What:           /sys/class/leds/SRWS1::<serial>::RPM14
+What:           /sys/class/leds/SRWS1::<serial>::RPM15
+What:           /sys/class/leds/SRWS1::<serial>::RPMALL
+Date:           Jan 2013
+KernelVersion:  3.9
+Contact:        Simon Wood <simon@mungewell.org>
+Description:    Provides a control for turning on/off the LEDs which form
+                an RPM meter on the front of the controller
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-thingm b/Documentation/ABI/testing/sysfs-driver-hid-thingm
new file mode 100644
index 000000000000..abcffeedd20a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-thingm
@@ -0,0 +1,23 @@
+What:           /sys/class/leds/blink1::<serial>/rgb
+Date:           January 2013
+Contact:        Vivien Didelot <vivien.didelot@savoirfairelinux.com>
+Description:    The ThingM blink1 is an USB RGB LED. The color notation is
+                3-byte hexadecimal. Read this attribute to get the last set
+                color. Write the 24-bit hexadecimal color to change the current
+                LED color. The default color is full white (0xFFFFFF).
+                For instance, set the color to green with: echo 00FF00 > rgb
+What:           /sys/class/leds/blink1::<serial>/fade
+Date:           January 2013
+Contact:        Vivien Didelot <vivien.didelot@savoirfairelinux.com>
+Description:    This attribute allows to set a fade time in milliseconds for
+                the next color change. Read the attribute to know the current
+                fade time. The default value is set to 0 (no fade time). For
+                instance, set a fade time of 2 seconds with: echo 2000 > fade
+What:           /sys/class/leds/blink1::<serial>/play
+Date:           January 2013
+Contact:        Vivien Didelot <vivien.didelot@savoirfairelinux.com>
+Description:    This attribute is used to play/pause the light patterns. Write 1
+                to start playing, 0 to stop. Reading this attribute returns the
+                current playing status.
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-ksm b/Documentation/ABI/testing/sysfs-kernel-mm-ksm
new file mode 100644
index 000000000000..73e653ee2481
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-ksm
@@ -0,0 +1,52 @@
+What:           /sys/kernel/mm/ksm
+Date:           September 2009
+KernelVersion:  2.6.32
+Contact:        Linux memory management mailing list <linux-mm@kvack.org>
+Description:    Interface for Kernel Samepage Merging (KSM)
+What:           /sys/kernel/mm/ksm/full_scans
+What:           /sys/kernel/mm/ksm/pages_shared
+What:           /sys/kernel/mm/ksm/pages_sharing
+What:           /sys/kernel/mm/ksm/pages_to_scan
+What:           /sys/kernel/mm/ksm/pages_unshared
+What:           /sys/kernel/mm/ksm/pages_volatile
+What:           /sys/kernel/mm/ksm/run
+What:           /sys/kernel/mm/ksm/sleep_millisecs
+Date:           September 2009
+Contact:        Linux memory management mailing list <linux-mm@kvack.org>
+Description:    Kernel Samepage Merging daemon sysfs interface
+                full_scans: how many times all mergeable areas have been
+                scanned.
+                pages_shared: how many shared pages are being used.
+                pages_sharing: how many more sites are sharing them i.e. how
+                much saved.
+                pages_to_scan: how many present pages to scan before ksmd goes
+                to sleep.
+                pages_unshared: how many pages unique but repeatedly checked
+                for merging.
+                pages_volatile: how many pages changing too fast to be placed
+                in a tree.
+                run: write 0 to disable ksm, read 0 while ksm is disabled.
+                        write 1 to run ksm, read 1 while ksm is running.
+                        write 2 to disable ksm and unmerge all its pages.
+                sleep_millisecs: how many milliseconds ksm should sleep between
+                scans.
+                See Documentation/vm/ksm.txt for more information.
+What:           /sys/kernel/mm/ksm/merge_across_nodes
+Date:           January 2013
+KernelVersion:  3.9
+Contact:        Linux memory management mailing list <linux-mm@kvack.org>
+Description:    Control merging pages across different NUMA nodes.
+                When it is set to 0 only pages from the same node are merged,
+                otherwise pages from all nodes can be merged together (default).
diff --git a/Documentation/ABI/testing/sysfs-platform-ts5500 b/Documentation/ABI/testing/sysfs-platform-ts5500
new file mode 100644
index 000000000000..c88375a537a1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-ts5500
@@ -0,0 +1,47 @@
+What:           /sys/devices/platform/ts5500/adc
+Date:           January 2013
+KernelVersion:  3.7
+Contact:        "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+                Indicates the presence of an A/D Converter. If it is present,
+                it will display "1", otherwise "0".
+What:           /sys/devices/platform/ts5500/ereset
+Date:           January 2013
+KernelVersion:  3.7
+Contact:        "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+                Indicates the presence of an external reset. If it is present,
+                it will display "1", otherwise "0".
+What:           /sys/devices/platform/ts5500/id
+Date:           January 2013
+KernelVersion:  3.7
+Contact:        "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+                Product ID of the TS board. TS-5500 ID is 0x60.
+What:           /sys/devices/platform/ts5500/jumpers
+Date:           January 2013
+KernelVersion:  3.7
+Contact:        "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+                Bitfield showing the jumpers' state. If a jumper is present,
+                the corresponding bit is set. For instance, 0x0e means jumpers
+                2, 3 and 4 are set.
+What:           /sys/devices/platform/ts5500/rs485
+Date:           January 2013
+KernelVersion:  3.7
+Contact:        "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+                Indicates the presence of the RS485 option. If it is present,
+                it will display "1", otherwise "0".
+What:           /sys/devices/platform/ts5500/sram
+Date:           January 2013
+KernelVersion:  3.7
+Contact:        "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+                Indicates the presence of the SRAM option. If it is present,
+                it will display "1", otherwise "0".
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 495e5ba1634c..e00b8f0dde52 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -546,15 +546,7 @@ config AUDIT
          logging of avc messages output).  Does not do system-call
          auditing without CONFIG_AUDITSYSCALL.
-Features that might still be considered unstable should be defined as
+Seriously dangerous features (such as write support for certain
-dependent on "EXPERIMENTAL":
-config SLUB
-        depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT
-        bool "SLUB (Unqueued Allocator)"
-        ...
-while seriously dangerous features (such as write support for certain
 filesystems) should advertise this prominently in their prompt string:
 config ADFS_FS_RW
diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl
index 42e7f030cb16..284ced7a228f 100644
--- a/Documentation/DocBook/80211.tmpl
+++ b/Documentation/DocBook/80211.tmpl
@@ -107,8 +107,8 @@
 !Finclude/net/cfg80211.h key_params
 !Finclude/net/cfg80211.h survey_info_flags
 !Finclude/net/cfg80211.h survey_info
-!Finclude/net/cfg80211.h beacon_parameters
+!Finclude/net/cfg80211.h cfg80211_beacon_data
-!Finclude/net/cfg80211.h plink_actions
+!Finclude/net/cfg80211.h cfg80211_ap_settings
 !Finclude/net/cfg80211.h station_parameters
 !Finclude/net/cfg80211.h station_info_flags
 !Finclude/net/cfg80211.h rate_info_flags
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 4ee2304f82f9..f9df3b872c16 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -743,6 +743,10 @@ char *date;</synopsis>
          These two operations are mandatory for GEM drivers that support DRM
          PRIME.
        </para>
+        <sect4>
+          <title>DRM PRIME Helper Functions Reference</title>
+!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
+        </sect4>
      </sect3>
      <sect3 id="drm-gem-objects-mapping">
        <title>GEM Objects Mapping</title>
@@ -978,10 +982,25 @@ int max_width, max_height;</synopsis>
        If the parameters are deemed valid, drivers then create, initialize and
        return an instance of struct <structname>drm_framebuffer</structname>.
        If desired the instance can be embedded in a larger driver-specific
-        structure. The new instance is initialized with a call to
+        structure. Drivers must fill its <structfield>width</structfield>,
-        <function>drm_framebuffer_init</function> which takes a pointer to DRM
+        <structfield>height</structfield>, <structfield>pitches</structfield>,
-        frame buffer operations (struct
+        <structfield>offsets</structfield>, <structfield>depth</structfield>,
-        <structname>drm_framebuffer_funcs</structname>). Frame buffer operations are
+        <structfield>bits_per_pixel</structfield> and
+        <structfield>pixel_format</structfield> fields from the values passed
+        through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
+        should call the <function>drm_helper_mode_fill_fb_struct</function>
+        helper function to do so.
+      </para>
+      <para>
+        The initailization of the new framebuffer instance is finalized with a
+        call to <function>drm_framebuffer_init</function> which takes a pointer
+        to DRM frame buffer operations (struct
+        <structname>drm_framebuffer_funcs</structname>). Note that this function
+        publishes the framebuffer and so from this point on it can be accessed
+        concurrently from other threads. Hence it must be the last step in the
+        driver's framebuffer initialization sequence. Frame buffer operations
+        are
        <itemizedlist>
          <listitem>
            <synopsis>int (*create_handle)(struct drm_framebuffer *fb,
@@ -1022,16 +1041,16 @@ int max_width, max_height;</synopsis>
        </itemizedlist>
      </para>
      <para>
-        After initializing the <structname>drm_framebuffer</structname>
+        The lifetime of a drm framebuffer is controlled with a reference count,
-        instance drivers must fill its <structfield>width</structfield>,
+        drivers can grab additional references with
-        <structfield>height</structfield>, <structfield>pitches</structfield>,
+        <function>drm_framebuffer_reference</function> </para> and drop them
-        <structfield>offsets</structfield>, <structfield>depth</structfield>,
+        again with <function>drm_framebuffer_unreference</function>. For
-        <structfield>bits_per_pixel</structfield> and
+        driver-private framebuffers for which the last reference is never
-        <structfield>pixel_format</structfield> fields from the values passed
+        dropped (e.g. for the fbdev framebuffer when the struct
-        through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
+        <structname>drm_framebuffer</structname> is embedded into the fbdev
-        should call the <function>drm_helper_mode_fill_fb_struct</function>
+        helper struct) drivers can manually clean up a framebuffer at module
-        helper function to do so.
+        unload time with
-      </para>
+        <function>drm_framebuffer_unregister_private</function>.
    </sect2>
    <sect2>
      <title>Output Polling</title>
@@ -1043,6 +1062,22 @@ int max_width, max_height;</synopsis>
        operation.
      </para>
    </sect2>
+    <sect2>
+      <title>Locking</title>
+      <para>
+        Beside some lookup structures with their own locking (which is hidden
+        behind the interface functions) most of the modeset state is protected
+        by the <code>dev-&lt;mode_config.lock</code> mutex and additionally
+        per-crtc locks to allow cursor updates, pageflips and similar operations
+        to occur concurrently with background tasks like output detection.
+        Operations which cross domains like a full modeset always grab all
+        locks. Drivers there need to protect resources shared between crtcs with
+        additional locking. They also need to be careful to always grab the
+        relevant crtc locks if a modset functions touches crtc state, e.g. for
+        load detection (which does only grab the <code>mode_config.lock</code>
+        to allow concurrent screen updates on live crtcs).
+      </para>
+    </sect2>
  </sect1>
  <!-- Internals: kms initialization and cleanup -->
@@ -1126,6 +1161,12 @@ int max_width, max_height;</synopsis>
            any new rendering to the frame buffer until the page flip completes.
          </para>
          <para>
+            If a page flip can be successfully scheduled the driver must set the
+            <code>drm_crtc-&lt;fb</code> field to the new framebuffer pointed to
+            by <code>fb</code>. This is important so that the reference counting
+            on framebuffers stays balanced.
+          </para>
+          <para>
            If a page flip is already pending, the
            <methodname>page_flip</methodname> operation must return
            -<errorname>EBUSY</errorname>.
@@ -1609,6 +1650,10 @@ void intel_crt_init(struct drm_device *dev)
        make its properties available to applications.
      </para>
    </sect2>
+    <sect2>
+      <title>KMS API Functions</title>
+!Edrivers/gpu/drm/drm_crtc.c
+    </sect2>
  </sect1>
  <!-- Internals: kms helper functions -->
@@ -2104,6 +2149,7 @@ void intel_crt_init(struct drm_device *dev)
      <title>fbdev Helper Functions Reference</title>
 !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
 !Edrivers/gpu/drm/drm_fb_helper.c
+!Iinclude/drm/drm_fb_helper.h
    </sect2>
    <sect2>
      <title>Display Port Helper Functions Reference</title>
@@ -2111,6 +2157,10 @@ void intel_crt_init(struct drm_device *dev)
 !Iinclude/drm/drm_dp_helper.h
 !Edrivers/gpu/drm/drm_dp_helper.c
    </sect2>
+    <sect2>
+      <title>EDID Helper Functions Reference</title>
+!Edrivers/gpu/drm/drm_edid.c
+    </sect2>
  </sect1>
  <!-- Internals: vertical blanking -->
diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl
index eee71426ecb8..d0758b241b23 100644
--- a/Documentation/DocBook/kernel-hacking.tmpl
+++ b/Documentation/DocBook/kernel-hacking.tmpl
@@ -945,7 +945,7 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
  <sect1 id="sym-exportsymbols">
   <title><function>EXPORT_SYMBOL()</function>
-    <filename class="headerfile">include/linux/module.h</filename></title>
+    <filename class="headerfile">include/linux/export.h</filename></title>
   <para>
    This is the classic method of exporting a symbol: dynamically
@@ -955,7 +955,7 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
  <sect1 id="sym-exportsymbols-gpl">
   <title><function>EXPORT_SYMBOL_GPL()</function>
-    <filename class="headerfile">include/linux/module.h</filename></title>
+    <filename class="headerfile">include/linux/export.h</filename></title>
   <para>
    Similar to <function>EXPORT_SYMBOL()</function> except that the
@@ -1185,13 +1185,6 @@ static struct block_device_operations opt_fops = {
    </para>
    <para>
-     You may well want to make your CONFIG option only visible if
-     <symbol>CONFIG_EXPERIMENTAL</symbol> is enabled: this serves as a
-     warning to users.  There many other fancy things you can do: see
-     the various <filename>Kconfig</filename> files for ideas.
-    </para>
-    <para>
     In your description of the option, make sure you address both the
     expert user and the user who knows nothing about your feature.  Mention
     incompatibilities and issues here.  <emphasis> Definitely
diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl
index 4ee4ba3509fc..f77358f96930 100644
--- a/Documentation/DocBook/kgdb.tmpl
+++ b/Documentation/DocBook/kgdb.tmpl
@@ -94,10 +94,8 @@
  <sect1 id="CompileKGDB">
    <title>Kernel config options for kgdb</title>
    <para>
-    To enable <symbol>CONFIG_KGDB</symbol> you should first turn on
+    To enable <symbol>CONFIG_KGDB</symbol> you should look under
-    "Prompt for development and/or incomplete code/drivers"
+    "Kernel debugging" and select "KGDB: kernel debugger".
-    (CONFIG_EXPERIMENTAL) in  "General setup", then under the
-    "Kernel debugging" select "KGDB: kernel debugger".
    </para>
    <para>
    While it is not a hard requirement that you have symbols in your
diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml
index 757488b24f4f..0197bcc7842d 100644
--- a/Documentation/DocBook/media/dvb/dvbapi.xml
+++ b/Documentation/DocBook/media/dvb/dvbapi.xml
@@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
 <title>LINUX DVB API</title>
-<subtitle>Version 5.8</subtitle>
+<subtitle>Version 5.10</subtitle>
 <!-- ADD THE CHAPTERS HERE -->
  <chapter id="dvb_introdution">
    &sub-intro;
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 957e3acaae8e..4a5eaeed0b9e 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -7,14 +7,41 @@ the capability ioctls weren't implemented yet via the new way.</para>
 <para>The typical usage for the <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant>
 API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters">
 struct <constant>dvb_frontend_parameters</constant></link> were used.</para>
+<section id="dtv-stats">
+<title>DTV stats type</title>
+<programlisting>
+struct dtv_stats {
+        __u8 scale;     /* enum fecap_scale_params type */
+        union {
+                __u64 uvalue;   /* for counters and relative scales */
+                __s64 svalue;   /* for 1/1000 dB measures */
+        };
+} __packed;
+</programlisting>
+</section>
+<section id="dtv-fe-stats">
+<title>DTV stats type</title>
+<programlisting>
+#define MAX_DTV_STATS   4
+struct dtv_fe_stats {
+        __u8 len;
+        struct dtv_stats stat[MAX_DTV_STATS];
+} __packed;
+</programlisting>
+</section>
 <section id="dtv-property">
 <title>DTV property type</title>
 <programlisting>
 /* Reserved fields should be set to 0 */
 struct dtv_property {
        __u32 cmd;
+        __u32 reserved[3];
        union {
                __u32 data;
+                struct dtv_fe_stats st;
                struct {
                        __u8 data[32];
                        __u32 len;
@@ -440,7 +467,7 @@ typedef enum fe_delivery_system {
                <title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
                <para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
                        ISDB-T hierarchical layers can be decoded simultaneously. For that
-                        reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para>
+                        reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders.</para>
                <para>ISDB-T has 3 hierarchical layers which each can use a part of the
                        available segments. The total number of segments over all layers has
                        to 13 in ISDB-T.</para>
@@ -850,6 +877,147 @@ enum fe_interleaving {
        <para>use the special macro LNA_AUTO to set LNA auto</para>
        </section>
 </section>
+        <section id="frontend-stat-properties">
+        <title>Frontend statistics indicators</title>
+        <para>The values are returned via <constant>dtv_property.stat</constant>.
+              If the property is supported, <constant>dtv_property.stat.len</constant> is bigger than zero.</para>
+        <para>For most delivery systems, <constant>dtv_property.stat.len</constant>
+              will be 1 if the stats is supported, and the properties will
+              return a single value for each parameter.</para>
+        <para>It should be noticed, however, that new OFDM delivery systems
+              like ISDB can use different modulation types for each group of
+              carriers. On such standards, up to 3 groups of statistics can be
+              provided, and <constant>dtv_property.stat.len</constant> is updated
+              to reflect the "global" metrics, plus one metric per each carrier
+              group (called "layer" on ISDB).</para>
+        <para>So, in order to be consistent with other delivery systems, the first
+              value at <link linkend="dtv-stats"><constant>dtv_property.stat.dtv_stats</constant></link>
+              array refers to the global metric. The other elements of the array
+              represent each layer, starting from layer A(index 1),
+              layer B (index 2) and so on.</para>
+        <para>The number of filled elements are stored at <constant>dtv_property.stat.len</constant>.</para>
+        <para>Each element of the <constant>dtv_property.stat.dtv_stats</constant> array consists on two elements:</para>
+        <itemizedlist mark='opencircle'>
+                <listitem><para><constant>svalue</constant> or <constant>uvalue</constant>, where
+                        <constant>svalue</constant> is for signed values of the measure (dB measures)
+                        and <constant>uvalue</constant> is for unsigned values (counters, relative scale)</para></listitem>
+                <listitem><para><constant>scale</constant> - Scale for the value. It can be:</para>
+                        <section id = "fecap-scale-params">
+                        <itemizedlist mark='bullet'>
+                                <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)</para></listitem>
+                                <listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 1/1000 dB</para></listitem>
+                                <listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem>
+                                <listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem>
+                        </itemizedlist>
+                        </section>
+                </listitem>
+        </itemizedlist>
+        <section id="DTV-STAT-SIGNAL-STRENGTH">
+                <title><constant>DTV_STAT_SIGNAL_STRENGTH</constant></title>
+                <para>Indicates the signal strength level at the analog part of the tuner or of the demod.</para>
+                <para>Possible scales for this metric are:</para>
+                <itemizedlist mark='bullet'>
+                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
+                        <listitem><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</listitem>
+                        <listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</listitem>
+                </itemizedlist>
+        </section>
+        <section id="DTV-STAT-CNR">
+                <title><constant>DTV_STAT_CNR</constant></title>
+                <para>Indicates the Signal to Noise ratio for the main carrier.</para>
+                <para>Possible scales for this metric are:</para>
+                <itemizedlist mark='bullet'>
+                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
+                        <listitem><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</listitem>
+                        <listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</listitem>
+                </itemizedlist>
+        </section>
+        <section id="DTV-STAT-PRE-ERROR-BIT-COUNT">
+                <title><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></title>
+                <para>Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).</para>
+                <para>This measure is taken during the same interval as <constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant>.</para>
+                <para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
+                <link linkend="DTV-STAT-PRE-TOTAL-BIT-COUNT"><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></link>.</para>
+                <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+                      The frontend may reset it when a channel/transponder is tuned.</para>
+                <para>Possible scales for this metric are:</para>
+                <itemizedlist mark='bullet'>
+                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
+                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</listitem>
+                </itemizedlist>
+        </section>
+        <section id="DTV-STAT-PRE-TOTAL-BIT-COUNT">
+                <title><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></title>
+                <para>Measures the amount of bits received before the inner code block, during the same period as
+                <link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
+                <para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
+                      as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
+                <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+                      The frontend may reset it when a channel/transponder is tuned.</para>
+                <para>Possible scales for this metric are:</para>
+                <itemizedlist mark='bullet'>
+                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
+                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
+                                 <link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</listitem>
+                </itemizedlist>
+        </section>
+        <section id="DTV-STAT-POST-ERROR-BIT-COUNT">
+                <title><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></title>
+                <para>Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).</para>
+                <para>This measure is taken during the same interval as <constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant>.</para>
+                <para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
+                <link linkend="DTV-STAT-POST-TOTAL-BIT-COUNT"><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></link>.</para>
+                <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+                      The frontend may reset it when a channel/transponder is tuned.</para>
+                <para>Possible scales for this metric are:</para>
+                <itemizedlist mark='bullet'>
+                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
+                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</listitem>
+                </itemizedlist>
+        </section>
+        <section id="DTV-STAT-POST-TOTAL-BIT-COUNT">
+                <title><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></title>
+                <para>Measures the amount of bits received after the inner coding, during the same period as
+                <link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
+                <para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
+                      as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
+                <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+                      The frontend may reset it when a channel/transponder is tuned.</para>
+                <para>Possible scales for this metric are:</para>
+                <itemizedlist mark='bullet'>
+                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
+                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
+                                 <link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</listitem>
+                </itemizedlist>
+        </section>
+        <section id="DTV-STAT-ERROR-BLOCK-COUNT">
+                <title><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></title>
+                <para>Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code).</para>
+                <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+                      The frontend may reset it when a channel/transponder is tuned.</para>
+                <para>Possible scales for this metric are:</para>
+                <itemizedlist mark='bullet'>
+                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
+                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</listitem>
+                </itemizedlist>
+        </section>
+        <section id="DTV-STAT-TOTAL-BLOCK-COUNT">
+                <title><constant>DTV-STAT_TOTAL_BLOCK_COUNT</constant></title>
+                <para>Measures the total number of blocks received during the same period as
+                <link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link> measurement was taken.</para>
+                <para>It can be used to calculate the PER indicator, by dividing
+                <link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>
+                by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para>
+                <para>Possible scales for this metric are:</para>
+                <itemizedlist mark='bullet'>
+                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
+                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring
+                        <link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</listitem>
+                </itemizedlist>
+        </section>
+        </section>
        <section id="frontend-property-terrestrial-systems">
        <title>Properties used on terrestrial delivery systems</title>
                <section id="dvbt-params">
@@ -871,6 +1039,7 @@ enum fe_interleaving {
                                <listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
                                <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
                        </itemizedlist>
+                        <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
                </section>
                <section id="dvbt2-params">
                        <title>DVB-T2 delivery system</title>
@@ -895,6 +1064,7 @@ enum fe_interleaving {
                        <listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
                        <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
                </itemizedlist>
+                <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
                </section>
                <section id="isdbt">
                <title>ISDB-T delivery system</title>
@@ -948,6 +1118,7 @@ enum fe_interleaving {
                        <listitem><para><link linkend="DTV-ISDBT-LAYER-SEGMENT-COUNT"><constant>DTV_ISDBT_LAYERC_SEGMENT_COUNT</constant></link></para></listitem>
                        <listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem>
                </itemizedlist>
+                <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
                </section>
                <section id="atsc-params">
                        <title>ATSC delivery system</title>
@@ -961,6 +1132,7 @@ enum fe_interleaving {
                                <listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
                                <listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
                        </itemizedlist>
+                        <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
                </section>
                <section id="atscmh-params">
                        <title>ATSC-MH delivery system</title>
@@ -988,6 +1160,7 @@ enum fe_interleaving {
                                <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
                                <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
                        </itemizedlist>
+                        <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
                </section>
                <section id="dtmb-params">
                        <title>DTMB delivery system</title>
@@ -1007,6 +1180,7 @@ enum fe_interleaving {
                                <listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
                                <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
                        </itemizedlist>
+                        <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
                </section>
        </section>
        <section id="frontend-property-cable-systems">
@@ -1028,6 +1202,7 @@ enum fe_interleaving {
                        <listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
                        <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
                </itemizedlist>
+                <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
        </section>
        <section id="dvbc-annex-b-params">
                <title>DVB-C Annex B delivery system</title>
@@ -1043,6 +1218,7 @@ enum fe_interleaving {
                        <listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
                        <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
                </itemizedlist>
+                <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
        </section>
        </section>
        <section id="frontend-property-satellital-systems">
@@ -1062,6 +1238,7 @@ enum fe_interleaving {
                        <listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
                        <listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
                </itemizedlist>
+                <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
                <para>Future implementations might add those two missing parameters:</para>
                <itemizedlist mark='opencircle'>
                        <listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
@@ -1077,6 +1254,7 @@ enum fe_interleaving {
                        <listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
                        <listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
                </itemizedlist>
+                <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
        </section>
        <section id="turbo-params">
                <title>Turbo code delivery system</title>
diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml
index 426c2526a454..df39ba395df0 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -230,7 +230,7 @@ typedef enum fe_status {
 <entry align="char">The frontend has found a DVB signal</entry>
 </row><row>
 <entry align="char">FE_HAS_VITERBI</entry>
-<entry align="char">The frontend FEC code is stable</entry>
+<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
 </row><row>
 <entry align="char">FE_HAS_SYNC</entry>
 <entry align="char">Syncronization bytes was found</entry>
diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml
index 73c6847436c9..ae06afbbb3a9 100644
--- a/Documentation/DocBook/media/v4l/common.xml
+++ b/Documentation/DocBook/media/v4l/common.xml
@@ -609,7 +609,7 @@ to zero and the <constant>VIDIOC_G_STD</constant>,
        <para>Applications can make use of the <xref linkend="input-capabilities" /> and
 <xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
 are available for the device.</para>
-&ENOTTY;.
        <para>See <xref linkend="buffer" /> for a rationale. Probably
 even USB cameras follow some well known video standard. It might have
 been better to explicitly indicate elsewhere if a device cannot live
diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml
index 3dd9e78815d1..104a1a2b8849 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2477,6 +2477,22 @@ that used it. It was originally scheduled for removal in 2.6.35.
      </orderedlist>
    </section>
+    <section>
+      <title>V4L2 in Linux 3.9</title>
+      <orderedlist>
+        <listitem>
+          <para>Added timestamp types to
+          <structfield>flags</structfield> field in
+          <structname>v4l2_buffer</structname>. See <xref
+          linkend="buffer-flags" />.</para>
+        </listitem>
+        <listitem>
+          <para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event
+          changes flag. See <xref linkend="changes-flags"/>.</para>
+        </listitem>
+      </orderedlist>
+    </section>
    <section id="other">
      <title>Relation of V4L2 to other Linux multimedia APIs</title>
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
index 7fe5be1d3bbb..9e8f85498678 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -203,29 +203,6 @@ and should not be used in new drivers and applications.</entry>
            <entry>boolean</entry>
            <entry>Mirror the picture vertically.</entry>
          </row>
-        <row>
-          <entry><constant>V4L2_CID_HCENTER_DEPRECATED</constant> (formerly <constant>V4L2_CID_HCENTER</constant>)</entry>
-            <entry>integer</entry>
-            <entry>Horizontal image centering. This control is
-deprecated. New drivers and applications should use the <link
-linkend="camera-controls">Camera class controls</link>
-<constant>V4L2_CID_PAN_ABSOLUTE</constant>,
-<constant>V4L2_CID_PAN_RELATIVE</constant> and
-<constant>V4L2_CID_PAN_RESET</constant> instead.</entry>
-          </row>
-          <row>
-            <entry><constant>V4L2_CID_VCENTER_DEPRECATED</constant>
-            (formerly <constant>V4L2_CID_VCENTER</constant>)</entry>
-            <entry>integer</entry>
-            <entry>Vertical image centering. Centering is intended to
-<emphasis>physically</emphasis> adjust cameras. For image cropping see
-<xref linkend="crop" />, for clipping <xref linkend="overlay" />. This
-control is deprecated. New drivers and applications should use the
-<link linkend="camera-controls">Camera class controls</link>
-<constant>V4L2_CID_TILT_ABSOLUTE</constant>,
-<constant>V4L2_CID_TILT_RELATIVE</constant> and
-<constant>V4L2_CID_TILT_RESET</constant> instead.</entry>
-          </row>
          <row id="v4l2-power-line-frequency">
            <entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry>
            <entry>enum</entry>
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index 388a34032653..e6c58559ca6b 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -477,7 +477,7 @@ rest should be evident.</para>
    <note>
      <title>Experimental</title>
-      <para>This is an <link linkend="experimental"> experimental </link>
+      <para>This is an <link linkend="experimental">experimental</link>
      interface and may change in the future.</para>
    </note>
@@ -488,7 +488,7 @@ DMA buffer from userspace using a file descriptor previously exported for a
 different or the same device (known as the importer role), or both. This
 section describes the DMABUF importer role API in V4L2.</para>
-    <para>Refer to <link linked="vidioc-expbuf"> DMABUF exporting </link> for
+    <para>Refer to <link linkend="vidioc-expbuf">DMABUF exporting</link> for
 details about exporting V4L2 buffers as DMABUF file descriptors.</para>
 <para>Input and output devices support the streaming I/O method when the
@@ -741,17 +741,19 @@ applications when an output stream.</entry>
            <entry>struct timeval</entry>
            <entry><structfield>timestamp</structfield></entry>
            <entry></entry>
-            <entry><para>For input streams this is the
+            <entry><para>For input streams this is time when the first data
-system time (as returned by the <function>gettimeofday()</function>
+            byte was captured, as returned by the
-function) when the first data byte was captured. For output streams
+            <function>clock_gettime()</function> function for the relevant
-the data will not be displayed before this time, secondary to the
+            clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
-nominal frame rate determined by the current video standard in
+            <xref linkend="buffer-flags" />. For output streams the data
-enqueued order. Applications can for example zero this field to
+            will not be displayed before this time, secondary to the nominal
-display frames as soon as possible. The driver stores the time at
+            frame rate determined by the current video standard in enqueued
-which the first data byte was actually sent out in the
+            order. Applications can for example zero this field to display
-<structfield>timestamp</structfield> field. This permits
+            frames as soon as possible. The driver stores the time at which
-applications to monitor the drift between the video and system
+            the first data byte was actually sent out in the
-clock.</para></entry>
+            <structfield>timestamp</structfield> field. This permits
+            applications to monitor the drift between the video and system
+            clock.</para></entry>
          </row>
          <row>
            <entry>&v4l2-timecode;</entry>
@@ -903,7 +905,7 @@ should set this to 0.</entry>
          </row>
          <row>
            <entry></entry>
-            <entry>__unsigned long</entry>
+            <entry>unsigned long</entry>
            <entry><structfield>userptr</structfield></entry>
            <entry>When the memory type in the containing &v4l2-buffer; is
              <constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace
@@ -1114,6 +1116,35 @@ Typically applications shall use this flag for output buffers if the data
 in this buffer has not been created by the CPU but by some DMA-capable unit,
 in which case caches have not been used.</entry>
          </row>
+          <row>
+            <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
+            <entry>0xe000</entry>
+            <entry>Mask for timestamp types below. To test the
+            timestamp type, mask out bits not belonging to timestamp
+            type by performing a logical and operation with buffer
+            flags and timestamp mask.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
+            <entry>0x0000</entry>
+            <entry>Unknown timestamp type. This type is used by
+            drivers before Linux 3.9 and may be either monotonic (see
+            below) or realtime (wall clock). Monotonic clock has been
+            favoured in embedded systems whereas most of the drivers
+            use the realtime clock. Either kinds of timestamps are
+            available in user space via
+            <function>clock_gettime(2)</function> using clock IDs
+            <constant>CLOCK_MONOTONIC</constant> and
+            <constant>CLOCK_REALTIME</constant>, respectively.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
+            <entry>0x2000</entry>
+            <entry>The buffer timestamp has been taken from the
+            <constant>CLOCK_MONOTONIC</constant> clock. To access the
+            same clock outside V4L2, use
+            <function>clock_gettime(2)</function> .</entry>
+          </row>
        </tbody>
      </tgroup>
    </table>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
index a990b34d911a..f3a3d459fcdf 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
@@ -6,7 +6,7 @@
      <refnamediv>
        <refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
        <refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname>
-        <refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
+        <refname id="V4L2-PIX-FMT-NV12MT-16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
        <refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
          non contiguous in memory. </refpurpose>
      </refnamediv>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
new file mode 100644
index 000000000000..29acc2098cc2
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+        <refentry>
+          <refmeta>
+            <refentrytitle>
+              V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
+              V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
+              V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
+              V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
+            </refentrytitle>
+            &manvol;
+          </refmeta>
+          <refnamediv>
+            <refname id="V4L2-PIX-FMT-SBGGR10ALAW8">
+              <constant>V4L2_PIX_FMT_SBGGR10ALAW8</constant>
+            </refname>
+            <refname id="V4L2-PIX-FMT-SGBRG10ALAW8">
+              <constant>V4L2_PIX_FMT_SGBRG10ALAW8</constant>
+            </refname>
+            <refname id="V4L2-PIX-FMT-SGRBG10ALAW8">
+              <constant>V4L2_PIX_FMT_SGRBG10ALAW8</constant>
+            </refname>
+            <refname id="V4L2-PIX-FMT-SRGGB10ALAW8">
+              <constant>V4L2_PIX_FMT_SRGGB10ALAW8</constant>
+            </refname>
+            <refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose>
+          </refnamediv>
+          <refsect1>
+            <title>Description</title>
+            <para>The following four pixel formats are raw sRGB / Bayer
+            formats with 10 bits per color compressed to 8 bits each,
+            using the A-LAW algorithm. Each color component consumes 8
+            bits of memory. In other respects this format is similar to
+            <xref linkend="V4L2-PIX-FMT-SRGGB8"></xref>.</para>
+          </refsect1>
+        </refentry>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
new file mode 100644
index 000000000000..c507c1f73cd0
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
@@ -0,0 +1,62 @@
+        <refentry id="V4L2-PIX-FMT-UV8">
+          <refmeta>
+            <refentrytitle>V4L2_PIX_FMT_UV8  ('UV8')</refentrytitle>
+            &manvol;
+          </refmeta>
+          <refnamediv>
+            <refname><constant>V4L2_PIX_FMT_UV8</constant></refname>
+            <refpurpose>UV plane interleaved</refpurpose>
+          </refnamediv>
+          <refsect1>
+            <title>Description</title>
+            <para>In this format there is no Y plane, Only CbCr plane. ie
+            (UV interleaved)</para>
+            <example>
+            <title>
+              <constant>V4L2_PIX_FMT_UV8</constant>
+               pixel image
+            </title>
+            <formalpara>
+              <title>Byte Order.</title>
+              <para>Each cell is one byte.
+                <informaltable frame="none">
+                <tgroup cols="5" align="center">
+                  <colspec align="left" colwidth="2*" />
+                  <tbody valign="top">
+                    <row>
+                      <entry>start&nbsp;+&nbsp;0:</entry>
+                      <entry>Cb<subscript>00</subscript></entry>
+                      <entry>Cr<subscript>00</subscript></entry>
+                      <entry>Cb<subscript>01</subscript></entry>
+                      <entry>Cr<subscript>01</subscript></entry>
+                    </row>
+                    <row>
+                      <entry>start&nbsp;+&nbsp;4:</entry>
+                      <entry>Cb<subscript>10</subscript></entry>
+                      <entry>Cr<subscript>10</subscript></entry>
+                      <entry>Cb<subscript>11</subscript></entry>
+                      <entry>Cr<subscript>11</subscript></entry>
+                    </row>
+                    <row>
+                      <entry>start&nbsp;+&nbsp;8:</entry>
+                      <entry>Cb<subscript>20</subscript></entry>
+                      <entry>Cr<subscript>20</subscript></entry>
+                      <entry>Cb<subscript>21</subscript></entry>
+                      <entry>Cr<subscript>21</subscript></entry>
+                    </row>
+                    <row>
+                      <entry>start&nbsp;+&nbsp;12:</entry>
+                      <entry>Cb<subscript>30</subscript></entry>
+                      <entry>Cr<subscript>30</subscript></entry>
+                      <entry>Cb<subscript>31</subscript></entry>
+                      <entry>Cr<subscript>31</subscript></entry>
+                    </row>
+                  </tbody>
+                </tgroup>
+                </informaltable>
+              </para>
+              </formalpara>
+            </example>
+          </refsect1>
+        </refentry>
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml
index bf94f417592c..99b8d2ad6e4f 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
    &sub-srggb8;
    &sub-sbggr16;
    &sub-srggb10;
+    &sub-srggb10alaw8;
    &sub-srggb10dpcm8;
    &sub-srggb12;
  </section>
@@ -701,6 +702,7 @@ information.</para>
    &sub-y12;
    &sub-y10b;
    &sub-y16;
+    &sub-uv8;
    &sub-yuyv;
    &sub-uyvy;
    &sub-yvyu;
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml
index a0a936455fae..cc51372ed5e0 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -353,9 +353,9 @@
        <listitem><para>The number of bits per pixel component. All components are
        transferred on the same number of bits. Common values are 8, 10 and 12.</para>
        </listitem>
-        <listitem><para>If the pixel components are DPCM-compressed, a mention of the
+        <listitem><para>The compression (optional). If the pixel components are
-        DPCM compression and the number of bits per compressed pixel component.</para>
+        ALAW- or DPCM-compressed, a mention of the compression scheme and the
-        </listitem>
+        number of bits per compressed pixel component.</para></listitem>
        <listitem><para>The number of bus samples per pixel. Pixels that are wider than
        the bus width must be transferred in multiple samples. Common values are
        1 and 2.</para></listitem>
@@ -504,6 +504,74 @@
              <entry>r<subscript>1</subscript></entry>
              <entry>r<subscript>0</subscript></entry>
            </row>
+            <row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8">
+              <entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry>
+              <entry>0x3015</entry>
+              <entry></entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>b<subscript>7</subscript></entry>
+              <entry>b<subscript>6</subscript></entry>
+              <entry>b<subscript>5</subscript></entry>
+              <entry>b<subscript>4</subscript></entry>
+              <entry>b<subscript>3</subscript></entry>
+              <entry>b<subscript>2</subscript></entry>
+              <entry>b<subscript>1</subscript></entry>
+              <entry>b<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8">
+              <entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry>
+              <entry>0x3016</entry>
+              <entry></entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>g<subscript>7</subscript></entry>
+              <entry>g<subscript>6</subscript></entry>
+              <entry>g<subscript>5</subscript></entry>
+              <entry>g<subscript>4</subscript></entry>
+              <entry>g<subscript>3</subscript></entry>
+              <entry>g<subscript>2</subscript></entry>
+              <entry>g<subscript>1</subscript></entry>
+              <entry>g<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8">
+              <entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry>
+              <entry>0x3017</entry>
+              <entry></entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>g<subscript>7</subscript></entry>
+              <entry>g<subscript>6</subscript></entry>
+              <entry>g<subscript>5</subscript></entry>
+              <entry>g<subscript>4</subscript></entry>
+              <entry>g<subscript>3</subscript></entry>
+              <entry>g<subscript>2</subscript></entry>
+              <entry>g<subscript>1</subscript></entry>
+              <entry>g<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8">
+              <entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry>
+              <entry>0x3018</entry>
+              <entry></entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>r<subscript>7</subscript></entry>
+              <entry>r<subscript>6</subscript></entry>
+              <entry>r<subscript>5</subscript></entry>
+              <entry>r<subscript>4</subscript></entry>
+              <entry>r<subscript>3</subscript></entry>
+              <entry>r<subscript>2</subscript></entry>
+              <entry>r<subscript>1</subscript></entry>
+              <entry>r<subscript>0</subscript></entry>
+            </row>
            <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8">
              <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry>
              <entry>0x300b</entry>
@@ -853,10 +921,16 @@
      <title>Packed YUV Formats</title>
      <para>Those data formats transfer pixel data as (possibly downsampled) Y, U
-      and V components. The format code is made of the following information.
+      and V components. Some formats include dummy bits in some of their samples
+      and are collectively referred to as "YDYC" (Y-Dummy-Y-Chroma) formats.
+      One cannot rely on the values of these dummy bits as those are undefined.
+      </para>
+      <para>The format code is made of the following information.
      <itemizedlist>
        <listitem><para>The Y, U and V components order code, as transferred on the
-        bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem>
+        bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no
+        dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC formats.
+        </para></listitem>
        <listitem><para>The number of bits per pixel component. All components are
        transferred on the same number of bits. Common values are 8, 10 and 12.</para>
        </listitem>
@@ -877,7 +951,21 @@
      U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>.
      </para>
-      <para>The following table lisst existing packet YUV formats.</para>
+        <para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> list existing packet YUV
+        formats and describes the organization of each pixel data in each sample.
+        When a format pattern is split across multiple samples each of the samples
+        in the pattern is described.</para>
+        <para>The role of each bit transferred over the bus is identified by one
+        of the following codes.</para>
+        <itemizedlist>
+           <listitem><para>y<subscript>x</subscript> for luma component bit number x</para></listitem>
+           <listitem><para>u<subscript>x</subscript> for blue chroma component bit number x</para></listitem>
+           <listitem><para>v<subscript>x</subscript> for red chroma component bit number x</para></listitem>
+           <listitem><para>- for non-available bits (for positions higher than the bus width)</para></listitem>
+           <listitem><para>d for dummy bits</para></listitem>
+        </itemizedlist>
      <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-yuv8">
        <title>YUV Formats</title>
@@ -885,27 +973,37 @@
          <colspec colname="id" align="left" />
          <colspec colname="code" align="center"/>
          <colspec colname="bit" />
-          <colspec colnum="4" colname="b19" align="center" />
+          <colspec colnum="4" colname="b29" align="center" />
-          <colspec colnum="5" colname="b18" align="center" />
+          <colspec colnum="5" colname="b28" align="center" />
-          <colspec colnum="6" colname="b17" align="center" />
+          <colspec colnum="6" colname="b27" align="center" />
-          <colspec colnum="7" colname="b16" align="center" />
+          <colspec colnum="7" colname="b26" align="center" />
-          <colspec colnum="8" colname="b15" align="center" />
+          <colspec colnum="8" colname="b25" align="center" />
-          <colspec colnum="9" colname="b14" align="center" />
+          <colspec colnum="9" colname="b24" align="center" />
-          <colspec colnum="10" colname="b13" align="center" />
+          <colspec colnum="10" colname="b23" align="center" />
-          <colspec colnum="11" colname="b12" align="center" />
+          <colspec colnum="11" colname="b22" align="center" />
-          <colspec colnum="12" colname="b11" align="center" />
+          <colspec colnum="12" colname="b21" align="center" />
-          <colspec colnum="13" colname="b10" align="center" />
+          <colspec colnum="13" colname="b20" align="center" />
-          <colspec colnum="14" colname="b09" align="center" />
+          <colspec colnum="14" colname="b19" align="center" />
-          <colspec colnum="15" colname="b08" align="center" />
+          <colspec colnum="15" colname="b18" align="center" />
-          <colspec colnum="16" colname="b07" align="center" />
+          <colspec colnum="16" colname="b17" align="center" />
-          <colspec colnum="17" colname="b06" align="center" />
+          <colspec colnum="17" colname="b16" align="center" />
-          <colspec colnum="18" colname="b05" align="center" />
+          <colspec colnum="18" colname="b15" align="center" />
-          <colspec colnum="19" colname="b04" align="center" />
+          <colspec colnum="19" colname="b14" align="center" />
-          <colspec colnum="20" colname="b03" align="center" />
+          <colspec colnum="20" colname="b13" align="center" />
-          <colspec colnum="21" colname="b02" align="center" />
+          <colspec colnum="21" colname="b12" align="center" />
-          <colspec colnum="22" colname="b01" align="center" />
+          <colspec colnum="22" colname="b11" align="center" />
-          <colspec colnum="23" colname="b00" align="center" />
+          <colspec colnum="23" colname="b10" align="center" />
-          <spanspec namest="b19" nameend="b00" spanname="b0" />
+          <colspec colnum="24" colname="b09" align="center" />
+          <colspec colnum="25" colname="b08" align="center" />
+          <colspec colnum="26" colname="b07" align="center" />
+          <colspec colnum="27" colname="b06" align="center" />
+          <colspec colnum="28" colname="b05" align="center" />
+          <colspec colnum="29" colname="b04" align="center" />
+          <colspec colnum="30" colname="b03" align="center" />
+          <colspec colnum="31" colname="b02" align="center" />
+          <colspec colnum="32" colname="b01" align="center" />
+          <colspec colnum="33" colname="b00" align="center" />
+          <spanspec namest="b29" nameend="b00" spanname="b0" />
          <thead>
            <row>
              <entry>Identifier</entry>
@@ -917,6 +1015,16 @@
              <entry></entry>
              <entry></entry>
              <entry>Bit</entry>
+              <entry>29</entry>
+              <entry>28</entry>
+              <entry>27</entry>
+              <entry>26</entry>
+              <entry>25</entry>
+              <entry>24</entry>
+              <entry>23</entry>
+              <entry>22</entry>
+              <entry>21</entry>
+              <entry>10</entry>
              <entry>19</entry>
              <entry>18</entry>
              <entry>17</entry>
@@ -944,16 +1052,8 @@
              <entry>V4L2_MBUS_FMT_Y8_1X8</entry>
              <entry>0x2001</entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -965,9 +1065,9 @@
              <entry>y<subscript>1</subscript></entry>
              <entry>y<subscript>0</subscript></entry>
            </row>
-            <row id="V4L2-MBUS-FMT-UYVY8-1_5X8">
+            <row id="V4L2-MBUS-FMT-UV8-1X8">
-              <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry>
+              <entry>V4L2_MBUS_FMT_UV8_1X8</entry>
-              <entry>0x2002</entry>
+              <entry>0x2015</entry>
              <entry></entry>
              <entry>-</entry>
              <entry>-</entry>
@@ -1006,6 +1106,40 @@
              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-UYVY8-1_5X8">
+              <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry>
+              <entry>0x2002</entry>
+              <entry></entry>
+              &dash-ent-10;
+              &dash-ent-10;
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-10;
+              &dash-ent-10;
+              <entry>-</entry>
+              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
              <entry>y<subscript>6</subscript></entry>
              <entry>y<subscript>5</subscript></entry>
@@ -1019,16 +1153,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1044,16 +1170,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>v<subscript>7</subscript></entry>
@@ -1069,16 +1187,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1094,16 +1204,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1119,16 +1221,8 @@
              <entry>V4L2_MBUS_FMT_VYUY8_1_5X8</entry>
              <entry>0x2003</entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>v<subscript>7</subscript></entry>
@@ -1144,16 +1238,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1169,16 +1255,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1194,16 +1272,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>u<subscript>7</subscript></entry>
@@ -1219,16 +1289,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1244,16 +1306,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1269,16 +1323,8 @@
              <entry>V4L2_MBUS_FMT_YUYV8_1_5X8</entry>
              <entry>0x2004</entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1294,16 +1340,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1319,16 +1357,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>u<subscript>7</subscript></entry>
@@ -1344,16 +1374,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1369,16 +1391,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1394,16 +1408,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>v<subscript>7</subscript></entry>
@@ -1419,16 +1425,8 @@
              <entry>V4L2_MBUS_FMT_YVYU8_1_5X8</entry>
              <entry>0x2005</entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1444,16 +1442,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1469,16 +1459,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>v<subscript>7</subscript></entry>
@@ -1494,16 +1476,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1519,16 +1493,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1544,16 +1510,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>u<subscript>7</subscript></entry>
@@ -1569,16 +1527,8 @@
              <entry>V4L2_MBUS_FMT_UYVY8_2X8</entry>
              <entry>0x2006</entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>u<subscript>7</subscript></entry>
@@ -1594,16 +1544,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1619,16 +1561,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>v<subscript>7</subscript></entry>
@@ -1644,16 +1578,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1669,16 +1595,8 @@
              <entry>V4L2_MBUS_FMT_VYUY8_2X8</entry>
              <entry>0x2007</entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>v<subscript>7</subscript></entry>
@@ -1694,16 +1612,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1719,16 +1629,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>u<subscript>7</subscript></entry>
@@ -1744,16 +1646,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1769,16 +1663,8 @@
              <entry>V4L2_MBUS_FMT_YUYV8_2X8</entry>
              <entry>0x2008</entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1794,16 +1680,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>u<subscript>7</subscript></entry>
@@ -1819,16 +1697,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1844,16 +1714,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>v<subscript>7</subscript></entry>
@@ -1869,16 +1731,8 @@
              <entry>V4L2_MBUS_FMT_YVYU8_2X8</entry>
              <entry>0x2009</entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1894,16 +1748,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>v<subscript>7</subscript></entry>
@@ -1919,16 +1765,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1944,16 +1782,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>u<subscript>7</subscript></entry>
@@ -1969,16 +1799,8 @@
              <entry>V4L2_MBUS_FMT_Y10_1X10</entry>
              <entry>0x200a</entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>y<subscript>9</subscript></entry>
              <entry>y<subscript>8</subscript></entry>
              <entry>y<subscript>7</subscript></entry>
@@ -1994,16 +1816,8 @@
              <entry>V4L2_MBUS_FMT_YUYV10_2X10</entry>
              <entry>0x200b</entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>y<subscript>9</subscript></entry>
              <entry>y<subscript>8</subscript></entry>
              <entry>y<subscript>7</subscript></entry>
@@ -2019,16 +1833,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>u<subscript>9</subscript></entry>
              <entry>u<subscript>8</subscript></entry>
              <entry>u<subscript>7</subscript></entry>
@@ -2044,16 +1850,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>y<subscript>9</subscript></entry>
              <entry>y<subscript>8</subscript></entry>
              <entry>y<subscript>7</subscript></entry>
@@ -2069,16 +1867,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>v<subscript>9</subscript></entry>
              <entry>v<subscript>8</subscript></entry>
              <entry>v<subscript>7</subscript></entry>
@@ -2094,16 +1884,8 @@
              <entry>V4L2_MBUS_FMT_YVYU10_2X10</entry>
              <entry>0x200c</entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>y<subscript>9</subscript></entry>
              <entry>y<subscript>8</subscript></entry>
              <entry>y<subscript>7</subscript></entry>
@@ -2119,16 +1901,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>v<subscript>9</subscript></entry>
              <entry>v<subscript>8</subscript></entry>
              <entry>v<subscript>7</subscript></entry>
@@ -2144,16 +1918,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>y<subscript>9</subscript></entry>
              <entry>y<subscript>8</subscript></entry>
              <entry>y<subscript>7</subscript></entry>
@@ -2169,16 +1935,8 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
+              &dash-ent-10;
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
-              <entry>-</entry>
              <entry>u<subscript>9</subscript></entry>
              <entry>u<subscript>8</subscript></entry>
              <entry>u<subscript>7</subscript></entry>
@@ -2194,6 +1952,7 @@
              <entry>V4L2_MBUS_FMT_Y12_1X12</entry>
              <entry>0x2013</entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
@@ -2219,6 +1978,7 @@
              <entry>V4L2_MBUS_FMT_UYVY8_1X16</entry>
              <entry>0x200f</entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
@@ -2244,6 +2004,7 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
@@ -2269,6 +2030,7 @@
              <entry>V4L2_MBUS_FMT_VYUY8_1X16</entry>
              <entry>0x2010</entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
@@ -2294,6 +2056,7 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
@@ -2319,6 +2082,7 @@
              <entry>V4L2_MBUS_FMT_YUYV8_1X16</entry>
              <entry>0x2011</entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
@@ -2344,6 +2108,7 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
@@ -2369,6 +2134,7 @@
              <entry>V4L2_MBUS_FMT_YVYU8_1X16</entry>
              <entry>0x2012</entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
@@ -2394,6 +2160,57 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
+              &dash-ent-10;
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-YDYUYDYV8-1X16">
+              <entry>V4L2_MBUS_FMT_YDYUYDYV8_1X16</entry>
+              <entry>0x2014</entry>
+              <entry></entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
              <entry>-</entry>
              <entry>-</entry>
              <entry>-</entry>
@@ -2415,10 +2232,61 @@
              <entry>u<subscript>1</subscript></entry>
              <entry>u<subscript>0</subscript></entry>
            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+              <entry>d</entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+            </row>
            <row id="V4L2-MBUS-FMT-YUYV10-1X20">
              <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry>
              <entry>0x200d</entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>y<subscript>9</subscript></entry>
              <entry>y<subscript>8</subscript></entry>
              <entry>y<subscript>7</subscript></entry>
@@ -2444,6 +2312,7 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>y<subscript>9</subscript></entry>
              <entry>y<subscript>8</subscript></entry>
              <entry>y<subscript>7</subscript></entry>
@@ -2469,6 +2338,7 @@
              <entry>V4L2_MBUS_FMT_YVYU10_1X20</entry>
              <entry>0x200e</entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>y<subscript>9</subscript></entry>
              <entry>y<subscript>8</subscript></entry>
              <entry>y<subscript>7</subscript></entry>
@@ -2494,6 +2364,7 @@
              <entry></entry>
              <entry></entry>
              <entry></entry>
+              &dash-ent-10;
              <entry>y<subscript>9</subscript></entry>
              <entry>y<subscript>8</subscript></entry>
              <entry>y<subscript>7</subscript></entry>
@@ -2515,6 +2386,41 @@
              <entry>u<subscript>1</subscript></entry>
              <entry>u<subscript>0</subscript></entry>
            </row>
+            <row id="V4L2-MBUS-FMT-YUV10-1X30">
+              <entry>V4L2_MBUS_FMT_YUV10_1X30</entry>
+              <entry>0x2014</entry>
+              <entry></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+            </row>
          </tbody>
        </tgroup>
      </table>
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index 4d110b1ad3e9..a3cce18384e9 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -140,6 +140,16 @@ structs, ioctls) must be noted in more detail in the history chapter
 applications. -->
      <revision>
+        <revnumber>3.9</revnumber>
+        <date>2012-12-03</date>
+        <authorinitials>sa, sn</authorinitials>
+        <revremark>Added timestamp types to v4l2_buffer.
+        Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control
+        event changes flag, see <xref linkend="changes-flags"/>.
+        </revremark>
+      </revision>
+      <revision>
        <revnumber>3.6</revnumber>
        <date>2012-07-02</date>
        <authorinitials>hv</authorinitials>
@@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark>
 </partinfo>
 <title>Video for Linux Two API Specification</title>
- <subtitle>Revision 3.6</subtitle>
+ <subtitle>Revision 3.9</subtitle>
  <chapter id="common">
    &sub-common;
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 98a856f9ec30..89891adb928a 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -261,6 +261,12 @@
            <entry>This control event was triggered because the control flags
                changed.</entry>
          </row>
+          <row>
+            <entry><constant>V4L2_EVENT_CTRL_CH_RANGE</constant></entry>
+            <entry>0x0004</entry>
+            <entry>This control event was triggered because the minimum,
+            maximum, step or the default value of the control changed.</entry>
+          </row>
        </tbody>
      </tgroup>
    </table>
diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
index 72dfbd20a802..e287c8fc803b 100644
--- a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
@@ -83,15 +83,14 @@ descriptor. The application may pass it to other DMABUF-aware devices. Refer to
 <link linkend="dmabuf">DMABUF importing</link> for details about importing
 DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it
 is no longer used to allow the associated memory to be reclaimed. </para>
  </refsect1>
  <refsect1>
-   <section>
+    <title>Examples</title>
-      <title>Examples</title>
-      <example>
+    <example>
-        <title>Exporting a buffer.</title>
+      <title>Exporting a buffer.</title>
-        <programlisting>
+      <programlisting>
 int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
 {
        &v4l2-exportbuffer; expbuf;
@@ -108,12 +107,12 @@ int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
        return 0;
 }
-        </programlisting>
+      </programlisting>
-      </example>
+    </example>
-      <example>
+    <example>
-        <title>Exporting a buffer using the multi-planar API.</title>
+      <title>Exporting a buffer using the multi-planar API.</title>
-        <programlisting>
+      <programlisting>
 int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
        int dmafd[], int n_planes)
 {
@@ -137,12 +136,9 @@ int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
        return 0;
 }
-        </programlisting>
+      </programlisting>
-      </example>
+    </example>
-   </section>
-  </refsect1>
-  <refsect1>
    <table pgwide="1" frame="none" id="v4l2-exportbuffer">
      <title>struct <structname>v4l2_exportbuffer</structname></title>
      <tgroup cols="3">
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml
index 12b1d0503e26..ee2820d6ca66 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml
@@ -64,7 +64,9 @@ return an &EINVAL;. When the <structfield>value</structfield> is out
 of bounds drivers can choose to take the closest valid value or return
 an &ERANGE;, whatever seems more appropriate. However,
 <constant>VIDIOC_S_CTRL</constant> is a write-only ioctl, it does not
-return the actual new value.</para>
+return the actual new value. If the <structfield>value</structfield>
+is inappropriate for the control (e.g. if it refers to an unsupported
+menu index of a menu control), then &EINVAL; is returned as well.</para>
    <para>These ioctls work only with user controls. For other
 control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or
@@ -99,7 +101,9 @@ application.</entry>
        <term><errorcode>EINVAL</errorcode></term>
        <listitem>
          <para>The &v4l2-control; <structfield>id</structfield> is
-invalid.</para>
+invalid or the <structfield>value</structfield> is inappropriate for
+the given control (i.e. if a menu item is selected that is not supported
+by the driver according to &VIDIOC-QUERYMENU;).</para>
        </listitem>
      </varlistentry>
      <varlistentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
index 0a4b90fcf2da..4e16112df992 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
@@ -106,7 +106,9 @@ value or if an error is returned.</para>
 &EINVAL;. When the value is out of bounds drivers can choose to take
 the closest valid value or return an &ERANGE;, whatever seems more
 appropriate. In the first case the new value is set in
-&v4l2-ext-control;.</para>
+&v4l2-ext-control;. If the new control value is inappropriate (e.g. the
+given menu index is not supported by the menu control), then this will
+also result in an &EINVAL; error.</para>
    <para>The driver will only set/get these controls if all control
 values are correct. This prevents the situation where only some of the
@@ -199,13 +201,46 @@ also be zero.</entry>
          <row>
            <entry>__u32</entry>
            <entry><structfield>error_idx</structfield></entry>
-            <entry>Set by the driver in case of an error. If it is equal
+            <entry><para>Set by the driver in case of an error. If the error is
-to <structfield>count</structfield>, then no actual changes were made to
+associated with a particular control, then <structfield>error_idx</structfield>
-controls. In other words, the error was not associated with setting a particular
+is set to the index of that control. If the error is not related to a specific
-control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
+control, or the validation step failed (see below), then
-were modified and control <structfield>error_idx</structfield> is the one that
+<structfield>error_idx</structfield> is set to <structfield>count</structfield>.
-caused the error. The <structfield>error_idx</structfield> value is undefined
+The value is undefined if the ioctl returned 0 (success).</para>
-if the ioctl returned 0 (success).</entry>
+<para>Before controls are read from/written to hardware a validation step
+takes place: this checks if all controls in the list are valid controls,
+if no attempt is made to write to a read-only control or read from a write-only
+control, and any other up-front checks that can be done without accessing the
+hardware. The exact validations done during this step are driver dependent
+since some checks might require hardware access for some devices, thus making
+it impossible to do those checks up-front. However, drivers should make a
+best-effort to do as many up-front checks as possible.</para>
+<para>This check is done to avoid leaving the hardware in an inconsistent state due
+to easy-to-avoid problems. But it leads to another problem: the application needs to
+know whether an error came from the validation step (meaning that the hardware
+was not touched) or from an error during the actual reading from/writing to hardware.</para>
+<para>The, in hindsight quite poor, solution for that is to set <structfield>error_idx</structfield>
+to <structfield>count</structfield> if the validation failed. This has the
+unfortunate side-effect that it is not possible to see which control failed the
+validation. If the validation was successful and the error happened while
+accessing the hardware, then <structfield>error_idx</structfield> is less than
+<structfield>count</structfield> and only the controls up to
+<structfield>error_idx-1</structfield> were read or written correctly, and the
+state of the remaining controls is undefined.</para>
+<para>Since <constant>VIDIOC_TRY_EXT_CTRLS</constant> does not access hardware
+there is also no need to handle the validation step in this special way,
+so <structfield>error_idx</structfield> will just be set to the control that
+failed the validation step instead of to <structfield>count</structfield>.
+This means that if <constant>VIDIOC_S_EXT_CTRLS</constant> fails with
+<structfield>error_idx</structfield> set to <structfield>count</structfield>,
+then you can call <constant>VIDIOC_TRY_EXT_CTRLS</constant> to try to discover
+the actual control that failed the validation step. Unfortunately, there
+is no <constant>TRY</constant> equivalent for <constant>VIDIOC_G_EXT_CTRLS</constant>.
+</para></entry>
          </row>
          <row>
            <entry>__u32</entry>
@@ -298,8 +333,10 @@ These controls are described in <xref
        <term><errorcode>EINVAL</errorcode></term>
        <listitem>
          <para>The &v4l2-ext-control; <structfield>id</structfield>
-is invalid or the &v4l2-ext-controls;
+is invalid, the &v4l2-ext-controls;
-<structfield>ctrl_class</structfield> is invalid. This error code is
+<structfield>ctrl_class</structfield> is invalid, or the &v4l2-ext-control;
+<structfield>value</structfield> was inappropriate (e.g. the given menu
+index is not supported by the driver). This error code is
 also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and
 <constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more
 control values are in conflict.</para>
diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
index 4c70215ae03f..d5a3c97b206a 100644
--- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
@@ -76,7 +76,7 @@ make sure the strings are properly NUL-terminated.</para></entry>
          <row>
            <entry>__u8</entry>
            <entry><structfield>card</structfield>[32]</entry>
-            <entry>Name of the device, a NUL-terminated ASCII string.
+            <entry>Name of the device, a NUL-terminated UTF-8 string.
 For example: "Yoyodyne TV/FM". One driver may support different brands
 or models of video hardware. This information is intended for users,
 for example in a menu of available devices. Since multiple TV cards of
diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl
index f2413acfe241..1f6593deb995 100644
--- a/Documentation/DocBook/media_api.tmpl
+++ b/Documentation/DocBook/media_api.tmpl
@@ -22,6 +22,7 @@
 <!-- LinuxTV v4l-dvb repository. -->
 <!ENTITY v4l-dvb                "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
+<!ENTITY dash-ent-10            "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
 ]>
 <book id="media_api">
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl
index ddb05e98af0d..95618159e29b 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -984,7 +984,7 @@ int main()
                return errno;
        }
        configfd = open(&quot;/sys/class/uio/uio0/device/config&quot;, O_RDWR);
-        if (uiofd &lt; 0) {
+        if (configfd &lt; 0) {
                perror(&quot;config open:&quot;);
                return errno;
        }
diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl
index fb32aead5a0b..bd6fee22c4dd 100644
--- a/Documentation/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl
@@ -871,9 +871,8 @@
      <para>
      This function itself doesn't allocate the data space. The data
      must be allocated manually beforehand, and its pointer is passed
-      as the argument. This pointer is used as the
+      as the argument. This pointer (<parameter>chip</parameter> in the
-      (<parameter>chip</parameter> identifier in the above example)
+      above example) is used as the identifier for the instance.
-      for the instance. 
      </para>
      <para>
@@ -2304,7 +2303,7 @@ struct _snd_pcm_runtime {
        <constant>SNDRV_PCM_INFO_XXX</constant>. Here, at least, you
        have to specify whether the mmap is supported and which
        interleaved format is supported.
-        When the is supported, add the
+        When the hardware supports mmap, add the
        <constant>SNDRV_PCM_INFO_MMAP</constant> flag here. When the
        hardware supports the interleaved or the non-interleaved
        formats, <constant>SNDRV_PCM_INFO_INTERLEAVED</constant> or
@@ -2898,7 +2897,7 @@ struct _snd_pcm_runtime {
        <para>
          When the pcm supports the pause operation (given in the info
-        field of the hardware table), the <constant>PAUSE_PUSE</constant>
+        field of the hardware table), the <constant>PAUSE_PUSH</constant>
        and <constant>PAUSE_RELEASE</constant> commands must be
        handled here, too. The former is the command to pause the pcm,
        and the latter to restart the pcm again. 
@@ -3085,7 +3084,7 @@ struct _snd_pcm_runtime {
      <section id="pcm-interface-interrupt-handler-timer">
        <title>High frequency timer interrupts</title>
        <para>
-        This happense when the hardware doesn't generate interrupts
+        This happens when the hardware doesn't generate interrupts
        at the period boundary but issues timer interrupts at a fixed
        timer rate (e.g. es1968 or ymfpci drivers). 
        In this case, you need to check the current hardware
@@ -3251,18 +3250,19 @@ struct _snd_pcm_runtime {
          <title>Example of Hardware Constraints for Channels</title>
          <programlisting>
 <![CDATA[
-  static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params,
+  static int hw_rule_channels_by_format(struct snd_pcm_hw_params *params,
                                        struct snd_pcm_hw_rule *rule)
  {
          struct snd_interval *c = hw_param_interval(params,
-                SNDRV_PCM_HW_PARAM_CHANNELS);
+                        SNDRV_PCM_HW_PARAM_CHANNELS);
          struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
-          struct snd_mask fmt;
+          struct snd_interval ch;
-          snd_mask_any(&fmt);    /* Init the struct */
+          snd_interval_any(&ch);
-          if (c->min < 2) {
+          if (f->bits[0] == SNDRV_PCM_FMTBIT_S16_LE) {
-                  fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
+                  ch.min = ch.max = 1;
-                  return snd_mask_refine(f, &fmt);
+                  ch.integer = 1;
+                  return snd_interval_refine(c, &ch);
          }
          return 0;
  }
@@ -3278,35 +3278,35 @@ struct _snd_pcm_runtime {
         <programlisting>
 <![CDATA[
  snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
-                      hw_rule_channels_by_format, 0, SNDRV_PCM_HW_PARAM_FORMAT,
+                      hw_rule_channels_by_format, NULL,
-                      -1);
+                      SNDRV_PCM_HW_PARAM_FORMAT, -1);
 ]]>
          </programlisting>
        </informalexample>
      </para>
      <para>
-        The rule function is called when an application sets the number of
+        The rule function is called when an application sets the PCM
-        channels. But an application can set the format before the number of
+        format, and it refines the number of channels accordingly.
-        channels. Thus you also need to define the inverse rule:
+        But an application may set the number of channels before
+        setting the format. Thus you also need to define the inverse rule:
       <example>
-         <title>Example of Hardware Constraints for Channels</title>
+         <title>Example of Hardware Constraints for Formats</title>
         <programlisting>
 <![CDATA[
-  static int hw_rule_channels_by_format(struct snd_pcm_hw_params *params,
+  static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params,
                                        struct snd_pcm_hw_rule *rule)
  {
          struct snd_interval *c = hw_param_interval(params,
-                        SNDRV_PCM_HW_PARAM_CHANNELS);
+                SNDRV_PCM_HW_PARAM_CHANNELS);
          struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
-          struct snd_interval ch;
+          struct snd_mask fmt;
-          snd_interval_any(&ch);
+          snd_mask_any(&fmt);    /* Init the struct */
-          if (f->bits[0] == SNDRV_PCM_FMTBIT_S16_LE) {
+          if (c->min < 2) {
-                  ch.min = ch.max = 1;
+                  fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
-                  ch.integer = 1;
+                  return snd_mask_refine(f, &fmt);
-                  return snd_interval_refine(c, &ch);
          }
          return 0;
  }
@@ -3321,8 +3321,8 @@ struct _snd_pcm_runtime {
         <programlisting>
 <![CDATA[
  snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_FORMAT,
-                      hw_rule_format_by_channels, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
+                      hw_rule_format_by_channels, NULL,
-                      -1);
+                      SNDRV_PCM_HW_PARAM_CHANNELS, -1);
 ]]>
          </programlisting>
        </informalexample>
diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt
index 75a9f2a0c43d..2d0a8f09475d 100644
--- a/Documentation/EDID/HOWTO.txt
+++ b/Documentation/EDID/HOWTO.txt
@@ -28,11 +28,30 @@ Makefile environment are given here.
 To create binary EDID and C source code files from the existing data
 material, simply type "make".
-If you want to create your own EDID file, copy the file 1024x768.S and
+If you want to create your own EDID file, copy the file 1024x768.S,
-replace the settings with your own data. The CRC value in the last line
+replace the settings with your own data and add a new target to the
+Makefile. Please note that the EDID data structure expects the timing
+values in a different way as compared to the standard X11 format.
+X11:
+HTimings:  hdisp hsyncstart hsyncend htotal
+VTimings:  vdisp vsyncstart vsyncend vtotal
+EDID:
+#define XPIX hdisp
+#define XBLANK htotal-hdisp
+#define XOFFSET hsyncstart-hdisp
+#define XPULSE hsyncend-hsyncstart
+#define YPIX vdisp
+#define YBLANK vtotal-vdisp
+#define YOFFSET (63+(vsyncstart-vdisp))
+#define YPULSE (63+(vsyncend-vsyncstart))
+The CRC value in the last line
  #define CRC 0x55
-is a bit tricky. After a first version of the binary data set is
+also is a bit tricky. After a first version of the binary data set is
-created, it must be be checked with the "edid-decode" utility which will
+created, it must be checked with the "edid-decode" utility which will
 most probably complain about a wrong CRC. Fortunately, the utility also
 displays the correct CRC which must then be inserted into the source
 file. After the make procedure is repeated, the EDID data set is ready
diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt
index 53e6fca146d7..a09178086c30 100644
--- a/Documentation/PCI/MSI-HOWTO.txt
+++ b/Documentation/PCI/MSI-HOWTO.txt
@@ -127,15 +127,42 @@ on the number of vectors that can be allocated; pci_enable_msi_block()
 returns as soon as it finds any constraint that doesn't allow the
 call to succeed.
-4.2.3 pci_disable_msi
+4.2.3 pci_enable_msi_block_auto
+int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *count)
+This variation on pci_enable_msi() call allows a device driver to request
+the maximum possible number of MSIs.  The MSI specification only allows
+interrupts to be allocated in powers of two, up to a maximum of 2^5 (32).
+If this function returns a positive number, it indicates that it has
+succeeded and the returned value is the number of allocated interrupts. In
+this case, the function enables MSI on this device and updates dev->irq to
+be the lowest of the new interrupts assigned to it.  The other interrupts
+assigned to the device are in the range dev->irq to dev->irq + returned
+value - 1.
+If this function returns a negative number, it indicates an error and
+the driver should not attempt to request any more MSI interrupts for
+this device.
+If the device driver needs to know the number of interrupts the device
+supports it can pass the pointer count where that number is stored. The
+device driver must decide what action to take if pci_enable_msi_block_auto()
+succeeds, but returns a value less than the number of interrupts supported.
+If the device driver does not need to know the number of interrupts
+supported, it can set the pointer count to NULL.
+4.2.4 pci_disable_msi
 void pci_disable_msi(struct pci_dev *dev)
 This function should be used to undo the effect of pci_enable_msi() or
-pci_enable_msi_block().  Calling it restores dev->irq to the pin-based
+pci_enable_msi_block() or pci_enable_msi_block_auto().  Calling it restores
-interrupt number and frees the previously allocated message signaled
+dev->irq to the pin-based interrupt number and frees the previously
-interrupt(s).  The interrupt may subsequently be assigned to another
+allocated message signaled interrupt(s).  The interrupt may subsequently be
-device, so drivers should not cache the value of dev->irq.
+assigned to another device, so drivers should not cache the value of
+dev->irq.
 Before calling this function, a device driver must always call free_irq()
 on any interrupt for which it previously called request_irq().
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
index 54469bc81b1c..94a656131885 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -63,8 +63,8 @@ from ACPI tables.
 Currently the kernel is not able to automatically determine from which ACPI
 device it should make the corresponding platform device so we need to add
 the ACPI device explicitly to acpi_platform_device_ids list defined in
-drivers/acpi/scan.c. This limitation is only for the platform devices, SPI
+drivers/acpi/acpi_platform.c. This limitation is only for the platform
-and I2C devices are created automatically as described below.
+devices, SPI and I2C devices are created automatically as described below.
 SPI serial bus support
 ~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/acpi/scan_handlers.txt b/Documentation/acpi/scan_handlers.txt
new file mode 100644
index 000000000000..3246ccf15992
--- /dev/null
+++ b/Documentation/acpi/scan_handlers.txt
@@ -0,0 +1,77 @@
+ACPI Scan Handlers
+Copyright (C) 2012, Intel Corporation
+Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+During system initialization and ACPI-based device hot-add, the ACPI namespace
+is scanned in search of device objects that generally represent various pieces
+of hardware.  This causes a struct acpi_device object to be created and
+registered with the driver core for every device object in the ACPI namespace
+and the hierarchy of those struct acpi_device objects reflects the namespace
+layout (i.e. parent device objects in the namespace are represented by parent
+struct acpi_device objects and analogously for their children).  Those struct
+acpi_device objects are referred to as "device nodes" in what follows, but they
+should not be confused with struct device_node objects used by the Device Trees
+parsing code (although their role is analogous to the role of those objects).
+During ACPI-based device hot-remove device nodes representing pieces of hardware
+being removed are unregistered and deleted.
+The core ACPI namespace scanning code in drivers/acpi/scan.c carries out basic
+initialization of device nodes, such as retrieving common configuration
+information from the device objects represented by them and populating them with
+appropriate data, but some of them require additional handling after they have
+been registered.  For example, if the given device node represents a PCI host
+bridge, its registration should cause the PCI bus under that bridge to be
+enumerated and PCI devices on that bus to be registered with the driver core.
+Similarly, if the device node represents a PCI interrupt link, it is necessary
+to configure that link so that the kernel can use it.
+Those additional configuration tasks usually depend on the type of the hardware
+component represented by the given device node which can be determined on the
+basis of the device node's hardware ID (HID).  They are performed by objects
+called ACPI scan handlers represented by the following structure:
+struct acpi_scan_handler {
+        const struct acpi_device_id *ids;
+        struct list_head list_node;
+        int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
+        void (*detach)(struct acpi_device *dev);
+};
+where ids is the list of IDs of device nodes the given handler is supposed to
+take care of, list_node is the hook to the global list of ACPI scan handlers
+maintained by the ACPI core and the .attach() and .detach() callbacks are
+executed, respectively, after registration of new device nodes and before
+unregistration of device nodes the handler attached to previously.
+The namespace scanning function, acpi_bus_scan(), first registers all of the
+device nodes in the given namespace scope with the driver core.  Then, it tries
+to match a scan handler against each of them using the ids arrays of the
+available scan handlers.  If a matching scan handler is found, its .attach()
+callback is executed for the given device node.  If that callback returns 1,
+that means that the handler has claimed the device node and is now responsible
+for carrying out any additional configuration tasks related to it.  It also will
+be responsible for preparing the device node for unregistration in that case.
+The device node's handler field is then populated with the address of the scan
+handler that has claimed it.
+If the .attach() callback returns 0, it means that the device node is not
+interesting to the given scan handler and may be matched against the next scan
+handler in the list.  If it returns a (negative) error code, that means that
+the namespace scan should be terminated due to a serious error.  The error code
+returned should then reflect the type of the error.
+The namespace trimming function, acpi_bus_trim(), first executes .detach()
+callbacks from the scan handlers of all device nodes in the given namespace
+scope (if they have scan handlers).  Next, it unregisters all of the device
+nodes in that scope.
+ACPI scan handlers can be added to the list maintained by the ACPI core with the
+help of the acpi_scan_add_handler() function taking a pointer to the new scan
+handler as an argument.  The order in which scan handlers are added to the list
+is the order in which they are matched against device nodes during namespace
+scans.
+All scan handles must be added to the list before acpi_bus_scan() is run for the
+first time and they cannot be removed from it.
diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index d758702fc03c..5f583af0a6e1 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -35,6 +35,8 @@ ffffffbc00000000	ffffffbdffffffff	   8GB		vmemmap
 ffffffbe00000000        ffffffbffbbfffff          ~8GB          [guard, future vmmemap]
+ffffffbffbc00000        ffffffbffbdfffff           2MB          earlyprintk device
 ffffffbffbe00000        ffffffbffbe0ffff          64KB          PCI I/O space
 ffffffbbffff0000        ffffffbcffffffff          ~2MB          [guard]
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index 27f2b21a9d5c..d9ca5be9b471 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
@@ -253,6 +253,8 @@ This performs an atomic exchange operation on the atomic variable v, setting
 the given new value.  It returns the old value that the atomic variable v had
 just before the operation.
+atomic_xchg requires explicit memory barriers around the operation.
        int atomic_cmpxchg(atomic_t *v, int old, int new);
 This performs an atomic compare exchange operation on the atomic value v,
diff --git a/Documentation/backlight/lp855x-driver.txt b/Documentation/backlight/lp855x-driver.txt
index 1529394cfe8b..18b06ca038ea 100644
--- a/Documentation/backlight/lp855x-driver.txt
+++ b/Documentation/backlight/lp855x-driver.txt
@@ -4,7 +4,7 @@ Kernel driver lp855x
 Backlight driver for LP855x ICs
 Supported chips:
-        Texas Instruments LP8550, LP8551, LP8552, LP8553 and LP8556
+        Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
 Author: Milo(Woogyom) Kim <milo.kim@ti.com>
@@ -24,7 +24,7 @@ Value : pwm based or register based
 2) chip_id
 The lp855x chip id.
-Value : lp8550/lp8551/lp8552/lp8553/lp8556
+Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
 Platform data for lp855x
 ------------------------
diff --git a/Documentation/cgroups/00-INDEX b/Documentation/cgroups/00-INDEX
index f78b90a35ad0..f5635a09c3f6 100644
--- a/Documentation/cgroups/00-INDEX
+++ b/Documentation/cgroups/00-INDEX
@@ -4,8 +4,6 @@ blkio-controller.txt
        - Description for Block IO Controller, implementation and usage details.
 cgroups.txt
        - Control Groups definition, implementation details, examples and API.
-cgroup_event_listener.c
-        - A user program for cgroup listener.
 cpuacct.txt
        - CPU Accounting Controller; account CPU usage for groups of tasks.
 cpusets.txt
diff --git a/Documentation/cgroups/cgroup_event_listener.c b/Documentation/cgroups/cgroup_event_listener.c
deleted file mode 100644
index 3e082f96dc12..000000000000
--- a/Documentation/cgroups/cgroup_event_listener.c
+++ /dev/null
@@ -1,110 +0,0 @@
-/*
- * cgroup_event_listener.c - Simple listener of cgroup events
- *
- * Copyright (C) Kirill A. Shutemov <kirill@shutemov.name>
- */
-#include <assert.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <libgen.h>
-#include <limits.h>
-#include <stdio.h>
-#include <string.h>
-#include <unistd.h>
-#include <sys/eventfd.h>
-#define USAGE_STR "Usage: cgroup_event_listener <path-to-control-file> <args>\n"
-int main(int argc, char **argv)
-{
-        int efd = -1;
-        int cfd = -1;
-        int event_control = -1;
-        char event_control_path[PATH_MAX];
-        char line[LINE_MAX];
-        int ret;
-        if (argc != 3) {
-                fputs(USAGE_STR, stderr);
-                return 1;
-        }
-        cfd = open(argv[1], O_RDONLY);
-        if (cfd == -1) {
-                fprintf(stderr, "Cannot open %s: %s\n", argv[1],
-                                strerror(errno));
-                goto out;
-        }
-        ret = snprintf(event_control_path, PATH_MAX, "%s/cgroup.event_control",
-                        dirname(argv[1]));
-        if (ret >= PATH_MAX) {
-                fputs("Path to cgroup.event_control is too long\n", stderr);
-                goto out;
-        }
-        event_control = open(event_control_path, O_WRONLY);
-        if (event_control == -1) {
-                fprintf(stderr, "Cannot open %s: %s\n", event_control_path,
-                                strerror(errno));
-                goto out;
-        }
-        efd = eventfd(0, 0);
-        if (efd == -1) {
-                perror("eventfd() failed");
-                goto out;
-        }
-        ret = snprintf(line, LINE_MAX, "%d %d %s", efd, cfd, argv[2]);
-        if (ret >= LINE_MAX) {
-                fputs("Arguments string is too long\n", stderr);
-                goto out;
-        }
-        ret = write(event_control, line, strlen(line) + 1);
-        if (ret == -1) {
-                perror("Cannot write to cgroup.event_control");
-                goto out;
-        }
-        while (1) {
-                uint64_t result;
-                ret = read(efd, &result, sizeof(result));
-                if (ret == -1) {
-                        if (errno == EINTR)
-                                continue;
-                        perror("Cannot read from eventfd");
-                        break;
-                }
-                assert(ret == sizeof(result));
-                ret = access(event_control_path, W_OK);
-                if ((ret == -1) && (errno == ENOENT)) {
-                                puts("The cgroup seems to have removed.");
-                                ret = 0;
-                                break;
-                }
-                if (ret == -1) {
-                        perror("cgroup.event_control "
-                                        "is not accessible any more");
-                        break;
-                }
-                printf("%s %s: crossed\n", argv[1], argv[2]);
-        }
-out:
-        if (efd >= 0)
-                close(efd);
-        if (event_control >= 0)
-                close(event_control);
-        if (cfd >= 0)
-                close(cfd);
-        return (ret != 0);
-}
diff --git a/Documentation/cgroups/memcg_test.txt b/Documentation/cgroups/memcg_test.txt
index fc8fa97a09ac..ce94a83a7d9a 100644
--- a/Documentation/cgroups/memcg_test.txt
+++ b/Documentation/cgroups/memcg_test.txt
@@ -399,8 +399,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
 9.10 Memory thresholds
        Memory controller implements memory thresholds using cgroups notification
-        API. You can use Documentation/cgroups/cgroup_event_listener.c to test
+        API. You can use tools/cgroup/cgroup_event_listener.c to test it.
-        it.
        (Shell-A) Create cgroup and run event listener
        # mkdir /cgroup/A
diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt
index c436096351f8..72f70b16d299 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -111,6 +111,12 @@ policy->governor		must contain the "default policy" for
 For setting some of these values, the frequency table helpers might be
 helpful. See the section 2 for more information on them.
+SMP systems normally have same clock source for a group of cpus. For these the
+.init() would be called only once for the first online cpu. Here the .init()
+routine must initialize policy->cpus with mask of all possible cpus (Online +
+Offline) that share the clock. Then the core would copy this mask onto
+policy->related_cpus and will reset policy->cpus to carry only online cpus.
 1.3 verify
 ------------
diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt
index 04f6b32993e6..ff2f28332cc4 100644
--- a/Documentation/cpu-freq/user-guide.txt
+++ b/Documentation/cpu-freq/user-guide.txt
@@ -190,11 +190,11 @@ scaling_max_freq		show the current "policy limits" (in
                                first set scaling_max_freq, then
                                scaling_min_freq.
-affected_cpus :                 List of CPUs that require software coordination
+affected_cpus :                 List of Online CPUs that require software
-                                of frequency.
+                                coordination of frequency.
-related_cpus :                  List of CPUs that need some sort of frequency
+related_cpus :                  List of Online + Offline CPUs that need software
-                                coordination, whether software or hardware.
+                                coordination of frequency.
 scaling_driver :                Hardware driver for cpufreq.
diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt
index 728c38c242d6..56fb62b09fc5 100644
--- a/Documentation/device-mapper/dm-raid.txt
+++ b/Documentation/device-mapper/dm-raid.txt
@@ -141,3 +141,4 @@ Version History
 1.2.0   Handle creation of arrays that contain failed devices.
 1.3.0   Added support for RAID 10
 1.3.1   Allow device replacement/rebuild for RAID 10
+1.3.2   Fix/improve redundancy checking for RAID10
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
index 07c65e3cdcbe..f4d04a067282 100644
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
@@ -3,9 +3,11 @@ Altera SOCFPGA System Manager
 Required properties:
 - compatible : "altr,sys-mgr"
 - reg : Should contain 1 register ranges(address and length)
+- cpu1-start-addr : CPU1 start address in hex.
 Example:
         sysmgr@ffd08000 {
                compatible = "altr,sys-mgr";
                reg = <0xffd08000 0x1000>;
+                cpu1-start-addr = <0xffd080c4>;
        };
diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
index 52478c83d0cc..20746e5abe6f 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -1,13 +1,14 @@
 * ARM architected timer
-ARM Cortex-A7 and Cortex-A15 have a per-core architected timer, which
+ARM cores may have a per-core architected timer, which provides per-cpu timers.
-provides per-cpu timers.
 The timer is attached to a GIC to deliver its per-processor interrupts.
 ** Timer node properties:
- compatible : Should at least contain "arm,armv7-timer".
+- compatible : Should at least contain one of
+        "arm,armv7-timer"
+        "arm,armv8-timer"
 - interrupts : Interrupt list for secure, non-secure, virtual and
  hypervisor timers, in that order.
diff --git a/Documentation/devicetree/bindings/arm/atmel-aic.txt b/Documentation/devicetree/bindings/arm/atmel-aic.txt
index 19078bf5cca8..ad031211b5b8 100644
--- a/Documentation/devicetree/bindings/arm/atmel-aic.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-aic.txt
@@ -4,7 +4,7 @@ Required properties:
 - compatible: Should be "atmel,<chip>-aic"
 - interrupt-controller: Identifies the node as an interrupt controller.
 - interrupt-parent: For single AIC system, it is an empty property.
- #interrupt-cells: The number of cells to define the interrupts. It sould be 3.
+- #interrupt-cells: The number of cells to define the interrupts. It should be 3.
  The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
  The second cell is used to specify flags:
    bits[3:0] trigger type and level flags:
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index 62eb8df1e08d..3dfb0c0384f5 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -42,7 +42,7 @@ Main node required properties:
 Optional
 - interrupts    : Interrupt source of the parent interrupt controller on
-  secondary GICs, or VGIC maintainance interrupt on primary GIC (see
+  secondary GICs, or VGIC maintenance interrupt on primary GIC (see
  below).
 - cpu-offset    : per-cpu offset within the distributor and cpu interface
@@ -74,7 +74,7 @@ Required properties:
  virtual interface control register base and size. The 2nd additional
  region is the GIC virtual cpu interface register base and size.
- interrupts : VGIC maintainance interrupt.
+- interrupts : VGIC maintenance interrupt.
 Example:
diff --git a/Documentation/devicetree/bindings/arm/kirkwood.txt b/Documentation/devicetree/bindings/arm/kirkwood.txt
new file mode 100644
index 000000000000..98cce9a653eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/kirkwood.txt
@@ -0,0 +1,27 @@
+Marvell Kirkwood Platforms Device Tree Bindings
+-----------------------------------------------
+Boards with a SoC of the Marvell Kirkwood
+shall have the following property:
+Required root node property:
+compatible: must contain "marvell,kirkwood";
+In order to support the kirkwood cpufreq driver, there must be a node
+cpus/cpu@0 with three clocks, "cpu_clk", "ddrclk" and "powersave",
+where the "powersave" clock is a gating clock used to switch the CPU
+between the "cpu_clk" and the "ddrclk".
+Example:
+        cpus {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                cpu@0 {
+                      device_type = "cpu";
+                      compatible = "marvell,sheeva-88SV131";
+                      clocks = <&core_clk 1>, <&core_clk 3>, <&gate_clk 11>;
+                      clock-names = "cpu_clk", "ddrclk", "powersave";
+                };
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index d0051a750587..f8288ea1b530 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -39,16 +39,16 @@ Boards:
 - OMAP3 Tobi with Overo : Commercial expansion board with daughter board
  compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
- OMAP4 SDP : Software Developement Board
+- OMAP4 SDP : Software Development Board
  compatible = "ti,omap4-sdp", "ti,omap4430"
 - OMAP4 PandaBoard : Low cost community board
  compatible = "ti,omap4-panda", "ti,omap4430"
- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x
+- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
  compatible = "ti,omap3-evm", "ti,omap3"
- AM335X EVM : Software Developement Board for AM335x
+- AM335X EVM : Software Development Board for AM335x
  compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
 - AM335X Bone : Low cost community board
diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
new file mode 100644
index 000000000000..433afe9cb590
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -0,0 +1,55 @@
+* Power State Coordination Interface (PSCI)
+Firmware implementing the PSCI functions described in ARM document number
+ARM DEN 0022A ("Power State Coordination Interface System Software on ARM
+processors") can be used by Linux to initiate various CPU-centric power
+operations.
+Issue A of the specification describes functions for CPU suspend, hotplug
+and migration of secure software.
+Functions are invoked by trapping to the privilege level of the PSCI
+firmware (specified as part of the binding below) and passing arguments
+in a manner similar to that specified by AAPCS:
+         r0             => 32-bit Function ID / return value
+        {r1 - r3}       => Parameters
+Note that the immediate field of the trapping instruction must be set
+to #0.
+Main node required properties:
+ - compatible    : Must be "arm,psci"
+ - method        : The method of calling the PSCI firmware. Permitted
+                   values are:
+                   "smc" : SMC #0, with the register assignments specified
+                           in this binding.
+                   "hvc" : HVC #0, with the register assignments specified
+                           in this binding.
+Main node optional properties:
+ - cpu_suspend   : Function ID for CPU_SUSPEND operation
+ - cpu_off       : Function ID for CPU_OFF operation
+ - cpu_on        : Function ID for CPU_ON operation
+ - migrate       : Function ID for MIGRATE operation
+Example:
+        psci {
+                compatible      = "arm,psci";
+                method          = "smc";
+                cpu_suspend     = <0x95c10000>;
+                cpu_off         = <0x95c10001>;
+                cpu_on          = <0x95c10002>;
+                migrate         = <0x95c10003>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/sirf.txt b/Documentation/devicetree/bindings/arm/sirf.txt
index 1881e1c6dda5..c6ba6d3c747f 100644
--- a/Documentation/devicetree/bindings/arm/sirf.txt
+++ b/Documentation/devicetree/bindings/arm/sirf.txt
@@ -1,3 +1,9 @@
-prima2 "cb" evaluation board
+CSR SiRFprimaII and SiRFmarco device tree bindings.
+========================================
 Required root node properties:
-    - compatible = "sirf,prima2-cb", "sirf,prima2";
+    - compatible:
+    - "sirf,prima2-cb" : prima2 "cb" evaluation board
+    - "sirf,marco-cb" : marco "cb" evaluation board
+    - "sirf,prima2" : prima2 device based board
+    - "sirf,marco" : marco device based board
diff --git a/Documentation/devicetree/bindings/arm/ste-nomadik.txt b/Documentation/devicetree/bindings/arm/ste-nomadik.txt
new file mode 100644
index 000000000000..19bca04b81c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ste-nomadik.txt
@@ -0,0 +1,27 @@
+ST-Ericsson Nomadik Device Tree Bindings
+For various board the "board" node may contain specific properties
+that pertain to this particular board, such as board-specific GPIOs.
+Boards with the Nomadik SoC include:
+S8815 "MiniKit" manufactured by Calao Systems:
+Required root node property:
+compatible="calaosystems,usb-s8815";
+Required node: usb-s8815
+Example:
+usb-s8815 {
+                ethernet-gpio {
+                        gpios = <&gpio3 19 0x1>;
+                        interrupts = <19 0x1>;
+                        interrupt-parent = <&gpio3>;
+                };
+                mmcsd-gpio {
+                        gpios = <&gpio3 16 0x1>;
+                };
+};
diff --git a/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt
index 6e69d2e5e766..ed9c85334436 100644
--- a/Documentation/devicetree/bindings/arm/tegra.txt
+++ b/Documentation/devicetree/bindings/arm/tegra.txt
@@ -1,14 +1,34 @@
 NVIDIA Tegra device tree bindings
 -------------------------------------------
-Boards with the tegra20 SoC shall have the following properties:
+SoCs
+-------------------------------------------
-Required root node property:
+Each device tree must specify which Tegra SoC it uses, using one of the
+following compatible values:
-compatible = "nvidia,tegra20";
+  nvidia,tegra20
+  nvidia,tegra30
-Boards with the tegra30 SoC shall have the following properties:
+Boards
+-------------------------------------------
-Required root node property:
+Each device tree must specify which one or more of the following
+board-specific compatible values:
-compatible = "nvidia,tegra30";
+  ad,medcom-wide
+  ad,plutux
+  ad,tamonten
+  ad,tec
+  compal,paz00
+  compulab,trimslice
+  nvidia,beaver
+  nvidia,cardhu
+  nvidia,cardhu-a02
+  nvidia,cardhu-a04
+  nvidia,harmony
+  nvidia,seaboard
+  nvidia,ventana
+  nvidia,whistler
+  toradex,colibri_t20-512
+  toradex,iris
diff --git a/Documentation/devicetree/bindings/arm/vt8500.txt b/Documentation/devicetree/bindings/arm/vt8500.txt
index d657832c6819..87dc1ddf4770 100644
--- a/Documentation/devicetree/bindings/arm/vt8500.txt
+++ b/Documentation/devicetree/bindings/arm/vt8500.txt
@@ -12,3 +12,11 @@ compatible = "wm,wm8505";
 Boards with the Wondermedia WM8650 SoC shall have the following properties:
 Required root node property:
 compatible = "wm,wm8650";
+Boards with the Wondermedia WM8750 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8750";
+Boards with the Wondermedia WM8850 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8850";
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
new file mode 100644
index 000000000000..5ddb2e9efaaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,84 @@
+Device tree bindings for OMAP general purpose memory controllers (GPMC)
+The actual devices are instantiated from the child nodes of a GPMC node.
+Required properties:
+ - compatible:          Should be set to one of the following:
+                        ti,omap2420-gpmc (omap2420)
+                        ti,omap2430-gpmc (omap2430)
+                        ti,omap3430-gpmc (omap3430 & omap3630)
+                        ti,omap4430-gpmc (omap4430 & omap4460 & omap543x)
+                        ti,am3352-gpmc   (am335x devices)
+ - reg:                 A resource specifier for the register space
+                        (see the example below)
+ - ti,hwmods:           Should be set to "ti,gpmc" until the DT transition is
+                        completed.
+ - #address-cells:      Must be set to 2 to allow memory address translation
+ - #size-cells:         Must be set to 1 to allow CS address passing
+ - gpmc,num-cs:         The maximum number of chip-select lines that controller
+                        can support.
+ - gpmc,num-waitpins:   The maximum number of wait pins that controller can
+                        support.
+ - ranges:              Must be set up to reflect the memory layout with four
+                        integer values for each chip-select line in use:
+                           <cs-number> 0 <physical address of mapping> <size>
+                        Currently, calculated values derived from the contents
+                        of the per-CS register GPMC_CONFIG7 (as set up by the
+                        bootloader) are used for the physical address decoding.
+                        As this will change in the future, filling correct
+                        values here is a requirement.
+Timing properties for child nodes. All are optional and default to 0.
+ - gpmc,sync-clk:       Minimum clock period for synchronous mode, in picoseconds
+ Chip-select signal timings corresponding to GPMC_CONFIG2:
+ - gpmc,cs-on:          Assertion time
+ - gpmc,cs-rd-off:      Read deassertion time
+ - gpmc,cs-wr-off:      Write deassertion time
+ ADV signal timings corresponding to GPMC_CONFIG3:
+ - gpmc,adv-on:         Assertion time
+ - gpmc,adv-rd-off:     Read deassertion time
+ - gpmc,adv-wr-off:     Write deassertion time
+ WE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,we-on:          Assertion time
+ - gpmc,we-off:         Deassertion time
+ OE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,oe-on:          Assertion time
+ - gpmc,oe-off:         Deassertion time
+ Access time and cycle time timings corresponding to GPMC_CONFIG5:
+ - gpmc,page-burst-access: Multiple access word delay
+ - gpmc,access:         Start-cycle to first data valid delay
+ - gpmc,rd-cycle:       Total read cycle time
+ - gpmc,wr-cycle:       Total write cycle time
+The following are only applicable to OMAP3+ and AM335x:
+ - gpmc,wr-access
+ - gpmc,wr-data-mux-bus
+Example for an AM33xx board:
+        gpmc: gpmc@50000000 {
+                compatible = "ti,am3352-gpmc";
+                ti,hwmods = "gpmc";
+                reg = <0x50000000 0x2000>;
+                interrupts = <100>;
+                gpmc,num-cs = <8>;
+                gpmc,num-waitpins = <2>;
+                #address-cells = <2>;
+                #size-cells = <1>;
+                ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
+                /* child nodes go here */
+        };
diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt b/Documentation/devicetree/bindings/clock/imx31-clock.txt
new file mode 100644
index 000000000000..19df842c694f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt
@@ -0,0 +1,91 @@
+* Clock bindings for Freescale i.MX31
+Required properties:
+- compatible: Should be "fsl,imx31-ccm"
+- reg: Address and length of the register set
+- interrupts: Should contain CCM interrupt
+- #clock-cells: Should be <1>
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell.  The following is a full list of i.MX31
+clocks and IDs.
+        Clock               ID
+        -----------------------
+        dummy                0
+        ckih                 1
+        ckil                 2
+        mpll                 3
+        spll                 4
+        upll                 5
+        mcu_main             6
+        hsp                  7
+        ahb                  8
+        nfc                  9
+        ipg                  10
+        per_div              11
+        per                  12
+        csi_sel              13
+        fir_sel              14
+        csi_div              15
+        usb_div_pre          16
+        usb_div_post         17
+        fir_div_pre          18
+        fir_div_post         19
+        sdhc1_gate           20
+        sdhc2_gate           21
+        gpt_gate             22
+        epit1_gate           23
+        epit2_gate           24
+        iim_gate             25
+        ata_gate             26
+        sdma_gate            27
+        cspi3_gate           28
+        rng_gate             29
+        uart1_gate           30
+        uart2_gate           31
+        ssi1_gate            32
+        i2c1_gate            33
+        i2c2_gate            34
+        i2c3_gate            35
+        hantro_gate          36
+        mstick1_gate         37
+        mstick2_gate         38
+        csi_gate             39
+        rtc_gate             40
+        wdog_gate            41
+        pwm_gate             42
+        sim_gate             43
+        ect_gate             44
+        usb_gate             45
+        kpp_gate             46
+        ipu_gate             47
+        uart3_gate           48
+        uart4_gate           49
+        uart5_gate           50
+        owire_gate           51
+        ssi2_gate            52
+        cspi1_gate           53
+        cspi2_gate           54
+        gacc_gate            55
+        emi_gate             56
+        rtic_gate            57
+        firi_gate            58
+Examples:
+clks: ccm@53f80000{
+        compatible = "fsl,imx31-ccm";
+        reg = <0x53f80000 0x4000>;
+        interrupts = <0 31 0x04 0 53 0x04>;
+        #clock-cells = <1>;
+};
+uart1: serial@43f90000 {
+        compatible = "fsl,imx31-uart", "fsl,imx21-uart";
+        reg = <0x43f90000 0x4000>;
+        interrupts = <45>;
+        clocks = <&clks 10>, <&clks 30>;
+        clock-names = "ipg", "per";
+        status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
index 7337005ef5e1..cffc93d97f54 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
@@ -89,7 +89,7 @@ ID	Clock	Peripheral
 16      xor1    XOR DMA 1
 17      crypto  CESA engine
 18      pex1    PCIe Cntrl 1
-19      ge1     Gigabit Ethernet 0
+19      ge1     Gigabit Ethernet 1
 20      tdm     Time Division Mplx
 Required properties:
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
new file mode 100644
index 000000000000..0921fac73528
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
@@ -0,0 +1,205 @@
+NVIDIA Tegra20 Clock And Reset Controller
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+Required properties :
+- compatible : Should be "nvidia,tegra20-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- #clock-cells : Should be 1.
+  In clock consumers, this cell represents the clock ID exposed by the CAR.
+  The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+  registers. These IDs often match those in the CAR's RST_DEVICES registers,
+  but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
+  this case, those clocks are assigned IDs above 95 in order to highlight
+  this issue. Implementations that interpret these clock IDs as bit values
+  within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
+  explicitly handle these special cases.
+  The balance of the clocks controlled by the CAR are assigned IDs of 96 and
+  above.
+  0     cpu
+  1     unassigned
+  2     unassigned
+  3     ac97
+  4     rtc
+  5     tmr
+  6     uart1
+  7     unassigned      (register bit affects uart2 and vfir)
+  8     gpio
+  9     sdmmc2
+  10    unassigned      (register bit affects spdif_in and spdif_out)
+  11    i2s1
+  12    i2c1
+  13    ndflash
+  14    sdmmc1
+  15    sdmmc4
+  16    twc
+  17    pwm
+  18    i2s2
+  19    epp
+  20    unassigned      (register bit affects vi and vi_sensor)
+  21    2d
+  22    usbd
+  23    isp
+  24    3d
+  25    ide
+  26    disp2
+  27    disp1
+  28    host1x
+  29    vcp
+  30    unassigned
+  31    cache2
+  32    mem
+  33    ahbdma
+  34    apbdma
+  35    unassigned
+  36    kbc
+  37    stat_mon
+  38    pmc
+  39    fuse
+  40    kfuse
+  41    sbc1
+  42    snor
+  43    spi1
+  44    sbc2
+  45    xio
+  46    sbc3
+  47    dvc
+  48    dsi
+  49    unassigned      (register bit affects tvo and cve)
+  50    mipi
+  51    hdmi
+  52    csi
+  53    tvdac
+  54    i2c2
+  55    uart3
+  56    unassigned
+  57    emc
+  58    usb2
+  59    usb3
+  60    mpe
+  61    vde
+  62    bsea
+  63    bsev
+  64    speedo
+  65    uart4
+  66    uart5
+  67    i2c3
+  68    sbc4
+  69    sdmmc3
+  70    pcie
+  71    owr
+  72    afi
+  73    csite
+  74    unassigned
+  75    avpucq
+  76    la
+  77    unassigned
+  78    unassigned
+  79    unassigned
+  80    unassigned
+  81    unassigned
+  82    unassigned
+  83    unassigned
+  84    irama
+  85    iramb
+  86    iramc
+  87    iramd
+  88    cram2
+  89    audio_2x        a/k/a audio_2x_sync_clk
+  90    clk_d
+  91    unassigned
+  92    sus
+  93    cdev1
+  94    cdev2
+  95    unassigned
+  96    uart2
+  97    vfir
+  98    spdif_in
+  99    spdif_out
+  100   vi
+  101   vi_sensor
+  102   tvo
+  103   cve
+  104   osc
+  105   clk_32k         a/k/a clk_s
+  106   clk_m
+  107   sclk
+  108   cclk
+  109   hclk
+  110   pclk
+  111   blink
+  112   pll_a
+  113   pll_a_out0
+  114   pll_c
+  115   pll_c_out1
+  116   pll_d
+  117   pll_d_out0
+  118   pll_e
+  119   pll_m
+  120   pll_m_out1
+  121   pll_p
+  122   pll_p_out1
+  123   pll_p_out2
+  124   pll_p_out3
+  125   pll_p_out4
+  126   pll_s
+  127   pll_u
+  128   pll_x
+  129   cop             a/k/a avp
+  130   audio           a/k/a audio_sync_clk
+  131   pll_ref
+  132   twd
+Example SoC include file:
+/ {
+        tegra_car: clock {
+                compatible = "nvidia,tegra20-car";
+                reg = <0x60006000 0x1000>;
+                #clock-cells = <1>;
+        };
+        usb@c5004000 {
+                clocks = <&tegra_car 58>; /* usb2 */
+        };
+};
+Example board file:
+/ {
+        clocks {
+                compatible = "simple-bus";
+                #address-cells = <1>;
+                #size-cells = <0>;
+                osc: clock@0 {
+                        compatible = "fixed-clock";
+                        reg = <0>;
+                        #clock-cells = <0>;
+                        clock-frequency = <12000000>;
+                };
+                clk_32k: clock@1 {
+                        compatible = "fixed-clock";
+                        reg = <1>;
+                        #clock-cells = <0>;
+                        clock-frequency = <32768>;
+                };
+        };
+        &tegra_car {
+                clocks = <&clk_32k> <&osc>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
new file mode 100644
index 000000000000..f3da3be5fcad
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
@@ -0,0 +1,262 @@
+NVIDIA Tegra30 Clock And Reset Controller
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+Required properties :
+- compatible : Should be "nvidia,tegra30-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- #clock-cells : Should be 1.
+  In clock consumers, this cell represents the clock ID exposed by the CAR.
+  The first 130 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+  registers. These IDs often match those in the CAR's RST_DEVICES registers,
+  but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
+  this case, those clocks are assigned IDs above 160 in order to highlight
+  this issue. Implementations that interpret these clock IDs as bit values
+  within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
+  explicitly handle these special cases.
+  The balance of the clocks controlled by the CAR are assigned IDs of 160 and
+  above.
+  0     cpu
+  1     unassigned
+  2     unassigned
+  3     unassigned
+  4     rtc
+  5     timer
+  6     uarta
+  7     unassigned      (register bit affects uartb and vfir)
+  8     gpio
+  9     sdmmc2
+  10    unassigned      (register bit affects spdif_in and spdif_out)
+  11    i2s1
+  12    i2c1
+  13    ndflash
+  14    sdmmc1
+  15    sdmmc4
+  16    unassigned
+  17    pwm
+  18    i2s2
+  19    epp
+  20    unassigned      (register bit affects vi and vi_sensor)
+  21    2d
+  22    usbd
+  23    isp
+  24    3d
+  25    unassigned
+  26    disp2
+  27    disp1
+  28    host1x
+  29    vcp
+  30    i2s0
+  31    cop_cache
+  32    mc
+  33    ahbdma
+  34    apbdma
+  35    unassigned
+  36    kbc
+  37    statmon
+  38    pmc
+  39    unassigned      (register bit affects fuse and fuse_burn)
+  40    kfuse
+  41    sbc1
+  42    nor
+  43    unassigned
+  44    sbc2
+  45    unassigned
+  46    sbc3
+  47    i2c5
+  48    dsia
+  49    unassigned      (register bit affects cve and tvo)
+  50    mipi
+  51    hdmi
+  52    csi
+  53    tvdac
+  54    i2c2
+  55    uartc
+  56    unassigned
+  57    emc
+  58    usb2
+  59    usb3
+  60    mpe
+  61    vde
+  62    bsea
+  63    bsev
+  64    speedo
+  65    uartd
+  66    uarte
+  67    i2c3
+  68    sbc4
+  69    sdmmc3
+  70    pcie
+  71    owr
+  72    afi
+  73    csite
+  74    pciex
+  75    avpucq
+  76    la
+  77    unassigned
+  78    unassigned
+  79    dtv
+  80    ndspeed
+  81    i2cslow
+  82    dsib
+  83    unassigned
+  84    irama
+  85    iramb
+  86    iramc
+  87    iramd
+  88    cram2
+  89    unassigned
+  90    audio_2x        a/k/a audio_2x_sync_clk
+  91    unassigned
+  92    csus
+  93    cdev2
+  94    cdev1
+  95    unassigned
+  96    cpu_g
+  97    cpu_lp
+  98    3d2
+  99    mselect
+  100   tsensor
+  101   i2s3
+  102   i2s4
+  103   i2c4
+  104   sbc5
+  105   sbc6
+  106   d_audio
+  107   apbif
+  108   dam0
+  109   dam1
+  110   dam2
+  111   hda2codec_2x
+  112   atomics
+  113   audio0_2x
+  114   audio1_2x
+  115   audio2_2x
+  116   audio3_2x
+  117   audio4_2x
+  118   audio5_2x
+  119   actmon
+  120   extern1
+  121   extern2
+  122   extern3
+  123   sata_oob
+  124   sata
+  125   hda
+  127   se
+  128   hda2hdmi
+  129   sata_cold
+  160   uartb
+  161   vfir
+  162   spdif_in
+  163   spdif_out
+  164   vi
+  165   vi_sensor
+  166   fuse
+  167   fuse_burn
+  168   cve
+  169   tvo
+  170   clk_32k
+  171   clk_m
+  172   clk_m_div2
+  173   clk_m_div4
+  174   pll_ref
+  175   pll_c
+  176   pll_c_out1
+  177   pll_m
+  178   pll_m_out1
+  179   pll_p
+  180   pll_p_out1
+  181   pll_p_out2
+  182   pll_p_out3
+  183   pll_p_out4
+  184   pll_a
+  185   pll_a_out0
+  186   pll_d
+  187   pll_d_out0
+  188   pll_d2
+  189   pll_d2_out0
+  190   pll_u
+  191   pll_x
+  192   pll_x_out0
+  193   pll_e
+  194   spdif_in_sync
+  195   i2s0_sync
+  196   i2s1_sync
+  197   i2s2_sync
+  198   i2s3_sync
+  199   i2s4_sync
+  200   vimclk
+  201   audio0
+  202   audio1
+  203   audio2
+  204   audio3
+  205   audio4
+  206   audio5
+  207   clk_out_1 (extern1)
+  208   clk_out_2 (extern2)
+  209   clk_out_3 (extern3)
+  210   sclk
+  211   blink
+  212   cclk_g
+  213   cclk_lp
+  214   twd
+  215   cml0
+  216   cml1
+  217   hclk
+  218   pclk
+Example SoC include file:
+/ {
+        tegra_car: clock {
+                compatible = "nvidia,tegra30-car";
+                reg = <0x60006000 0x1000>;
+                #clock-cells = <1>;
+        };
+        usb@c5004000 {
+                clocks = <&tegra_car 58>; /* usb2 */
+        };
+};
+Example board file:
+/ {
+        clocks {
+                compatible = "simple-bus";
+                #address-cells = <1>;
+                #size-cells = <0>;
+                osc: clock@0 {
+                        compatible = "fixed-clock";
+                        reg = <0>;
+                        #clock-cells = <0>;
+                        clock-frequency = <12000000>;
+                };
+                clk_32k: clock@1 {
+                        compatible = "fixed-clock";
+                        reg = <1>;
+                        #clock-cells = <0>;
+                        clock-frequency = <32768>;
+                };
+        };
+        &tegra_car {
+                clocks = <&clk_32k> <&osc>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/clock/prima2-clock.txt b/Documentation/devicetree/bindings/clock/prima2-clock.txt
new file mode 100644
index 000000000000..5016979c0f78
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/prima2-clock.txt
@@ -0,0 +1,73 @@
+* Clock bindings for CSR SiRFprimaII
+Required properties:
+- compatible: Should be "sirf,prima2-clkc"
+- reg: Address and length of the register set
+- interrupts: Should contain clock controller interrupt
+- #clock-cells: Should be <1>
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell.  The following is a full list of prima2
+clocks and IDs.
+        Clock                   ID
+        ---------------------------
+        rtc                     0
+        osc                     1
+        pll1                    2
+        pll2                    3
+        pll3                    4
+        mem                     5
+        sys                     6
+        security                7
+        dsp                     8
+        gps                     9
+        mf                      10
+        io                      11
+        cpu                     12
+        uart0                   13
+        uart1                   14
+        uart2                   15
+        tsc                     16
+        i2c0                    17
+        i2c1                    18
+        spi0                    19
+        spi1                    20
+        pwmc                    21
+        efuse                   22
+        pulse                   23
+        dmac0                   24
+        dmac1                   25
+        nand                    26
+        audio                   27
+        usp0                    28
+        usp1                    29
+        usp2                    30
+        vip                     31
+        gfx                     32
+        mm                      33
+        lcd                     34
+        vpp                     35
+        mmc01                   36
+        mmc23                   37
+        mmc45                   38
+        usbpll                  39
+        usb0                    40
+        usb1                    41
+Examples:
+clks: clock-controller@88000000 {
+        compatible = "sirf,prima2-clkc";
+        reg = <0x88000000 0x1000>;
+        interrupts = <3>;
+        #clock-cells = <1>;
+};
+i2c0: i2c@b00e0000 {
+        cell-index = <0>;
+        compatible = "sirf,prima2-i2c";
+        reg = <0xb00e0000 0x10000>;
+        interrupts = <24>;
+        clocks = <&clks 17>;
+};
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index fc9ce6f1688c..e4022776ac6e 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -54,8 +54,13 @@ PROPERTIES
   - compatible
      Usage: required
      Value type: <string>
-      Definition: Must include "fsl,sec-v4.0". Also includes SEC
+      Definition: Must include "fsl,sec-v4.0"
-           ERA versions (optional) with which the device is compatible.
+   - fsl,sec-era
+      Usage: optional
+      Value type: <u32>
+      Definition: A standard property. Define the 'ERA' of the SEC
+          device.
   - #address-cells
       Usage: required
@@ -107,7 +112,8 @@ PROPERTIES
 EXAMPLE
        crypto@300000 {
-                compatible = "fsl,sec-v4.0", "fsl,sec-era-v2.0";
+                compatible = "fsl,sec-v4.0";
+                fsl,sec-era = <2>;
                #address-cells = <1>;
                #size-cells = <1>;
                reg = <0x300000 0x10000>;
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt b/Documentation/devicetree/bindings/dma/arm-pl330.txt
index 36e27d54260b..267565894db9 100644
--- a/Documentation/devicetree/bindings/dma/arm-pl330.txt
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -10,7 +10,11 @@ Required properties:
  - interrupts: interrupt number to the cpu.
 Optional properties:
- dma-coherent      : Present if dma operations are coherent
+  - dma-coherent      : Present if dma operations are coherent
+  - #dma-cells: must be <1>. used to represent the number of integer
+    cells in the dmas property of client device.
+  - dma-channels: contains the total number of DMA channels supported by the DMAC
+  - dma-requests: contains the total number of DMA requests supported by the DMAC
 Example:
@@ -18,16 +22,23 @@ Example:
                compatible = "arm,pl330", "arm,primecell";
                reg = <0x12680000 0x1000>;
                interrupts = <99>;
+                #dma-cells = <1>;
+                #dma-channels = <8>;
+                #dma-requests = <32>;
        };
 Client drivers (device nodes requiring dma transfers from dev-to-mem or
-mem-to-dev) should specify the DMA channel numbers using a two-value pair
+mem-to-dev) should specify the DMA channel numbers and dma channel names
 as shown below.
  [property name]  = <[phandle of the dma controller] [dma request id]>;
+  [property name]  = <[dma channel name]>
      where 'dma request id' is the dma request number which is connected
-      to the client controller. The 'property name' is recommended to be
+      to the client controller. The 'property name' 'dmas' and 'dma-names'
-      of the form <name>-dma-channel.
+      as required by the generic dma device tree binding helpers. The dma
+      names correspond 1:1 with the dma request ids in the dmas property.
-  Example:  tx-dma-channel = <&pdma0 12>;
+  Example:  dmas = <&pdma0 12
+                    &pdma1 11>;
+            dma-names = "tx", "rx";
diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000000000000..8f504e6bae14
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,81 @@
+* Generic DMA Controller and DMA request bindings
+Generic binding to provide a way for a driver using DMA Engine to retrieve the
+DMA request or channel information that goes from a hardware device to a DMA
+controller.
+* DMA controller
+Required property:
+- #dma-cells:           Must be at least 1. Used to provide DMA controller
+                        specific information. See DMA client binding below for
+                        more details.
+Optional properties:
+- dma-channels:         Number of DMA channels supported by the controller.
+- dma-requests:         Number of DMA requests signals supported by the
+                        controller.
+Example:
+        dma: dma@48000000 {
+                compatible = "ti,omap-sdma";
+                reg = <0x48000000 0x1000>;
+                interrupts = <0 12 0x4
+                              0 13 0x4
+                              0 14 0x4
+                              0 15 0x4>;
+                #dma-cells = <1>;
+                dma-channels = <32>;
+                dma-requests = <127>;
+        };
+* DMA client
+Client drivers should specify the DMA property using a phandle to the controller
+followed by DMA controller specific data.
+Required property:
+- dmas:                 List of one or more DMA specifiers, each consisting of
+                        - A phandle pointing to DMA controller node
+                        - A number of integer cells, as determined by the
+                          #dma-cells property in the node referenced by phandle
+                          containing DMA controller specific information. This
+                          typically contains a DMA request line number or a
+                          channel number, but can contain any data that is used
+                          required for configuring a channel.
+- dma-names:            Contains one identifier string for each DMA specifier in
+                        the dmas property. The specific strings that can be used
+                        are defined in the binding of the DMA client device.
+                        Multiple DMA specifiers can be used to represent
+                        alternatives and in this case the dma-names for those
+                        DMA specifiers must be identical (see examples).
+Examples:
+1. A device with one DMA read channel, one DMA write channel:
+        i2c1: i2c@1 {
+                ...
+                dmas = <&dma 2          /* read channel */
+                        &dma 3>;        /* write channel */
+                dma-names = "rx", "tx";
+                ...
+        };
+2. A single read-write channel with three alternative DMA controllers:
+        dmas = <&dma1 5
+                &dma2 7
+                &dma3 2>;
+        dma-names = "rx-tx", "rx-tx", "rx-tx";
+3. A device with three channels, one of which has two alternatives:
+        dmas = <&dma1 2                 /* read channel */
+                &dma1 3                 /* write channel */
+                &dma2 0                 /* error read */
+                &dma3 0>;               /* alternative error read */
+        dma-names = "rx", "tx", "error", "error";
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index c0d85dbcada5..5bb3dfb6f1d8 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -6,6 +6,26 @@ Required properties:
 - interrupt-parent: Should be the phandle for the interrupt controller
  that services interrupts for this device
 - interrupt: Should contain the DMAC interrupt number
+- nr_channels: Number of channels supported by hardware
+- is_private: The device channels should be marked as private and not for by the
+  general purpose DMA channel allocator. False if not passed.
+- chan_allocation_order: order of allocation of channel, 0 (default): ascending,
+  1: descending
+- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
+  increase from chan n->0
+- block_size: Maximum block size supported by the controller
+- nr_masters: Number of AHB masters supported by the controller
+- data_width: Maximum data width supported by hardware per AHB master
+  (0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
+- slave_info:
+        - bus_id: name of this device channel, not just a device name since
+          devices may have more than one channel e.g. "foo_tx". For using the
+          dw_generic_filter(), slave drivers must pass exactly this string as
+          param to filter function.
+        - cfg_hi: Platform-specific initializer for the CFG_HI register
+        - cfg_lo: Platform-specific initializer for the CFG_LO register
+        - src_master: src master for transfers on allocated channel.
+        - dst_master: dest master for transfers on allocated channel.
 Example:
@@ -14,4 +34,28 @@ Example:
                reg = <0xfc000000 0x1000>;
                interrupt-parent = <&vic1>;
                interrupts = <12>;
+                nr_channels = <8>;
+                chan_allocation_order = <1>;
+                chan_priority = <1>;
+                block_size = <0xfff>;
+                nr_masters = <2>;
+                data_width = <3 3 0 0>;
+                slave_info {
+                        uart0-tx {
+                                bus_id = "uart0-tx";
+                                cfg_hi = <0x4000>;      /* 0x8 << 11 */
+                                cfg_lo = <0>;
+                                src_master = <0>;
+                                dst_master = <1>;
+                        };
+                        spi0-tx {
+                                bus_id = "spi0-tx";
+                                cfg_hi = <0x2000>;      /* 0x4 << 11 */
+                                cfg_lo = <0>;
+                                src_master = <0>;
+                                dst_master = <0>;
+                        };
+                };
        };
diff --git a/Documentation/devicetree/bindings/drm/exynos/g2d.txt b/Documentation/devicetree/bindings/drm/exynos/g2d.txt
new file mode 100644
index 000000000000..1eb124d35a99
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/g2d.txt
@@ -0,0 +1,22 @@
+Samsung 2D Graphic Accelerator using DRM frame work
+Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block Transfer.
+We set the drawing-context registers for configuring rendering parameters and
+then start rendering.
+This driver is for SOCs which contain G2D IPs with version 4.1.
+Required properties:
+        -compatible:
+                should be "samsung,exynos-g2d-41".
+        -reg:
+                physical base address of the controller and length
+                of memory mapped region.
+        -interrupts:
+                interrupt combiner values.
+Example:
+        g2d {
+                compatible = "samsung,exynos-g2d-41";
+                reg = <0x10850000 0x1000>;
+                interrupts = <0 91 0>;
+        };
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/panel.txt b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
new file mode 100644
index 000000000000..9301c330d1a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
@@ -0,0 +1,59 @@
+Device-Tree bindings for tilcdc DRM generic panel output driver
+Required properties:
+ - compatible: value should be "ti,tilcdc,panel".
+ - panel-info: configuration info to configure LCDC correctly for the panel
+   - ac-bias: AC Bias Pin Frequency
+   - ac-bias-intrpt: AC Bias Pin Transitions per Interrupt
+   - dma-burst-sz: DMA burst size
+   - bpp: Bits per pixel
+   - fdd: FIFO DMA Request Delay
+   - sync-edge: Horizontal and Vertical Sync Edge: 0=rising 1=falling
+   - sync-ctrl: Horizontal and Vertical Sync: Control: 0=ignore
+   - raster-order: Raster Data Order Select: 1=Most-to-least 0=Least-to-most
+   - fifo-th: DMA FIFO threshold
+ - display-timings: typical videomode of lcd panel.  Multiple video modes
+   can be listed if the panel supports multiple timings, but the 'native-mode'
+   should be the preferred/default resolution.  Refer to
+   Documentation/devicetree/bindings/video/display-timing.txt for display
+   timing binding details.
+Recommended properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure
+   muxing properly for pins that connect to TFP410 device
+Example:
+        /* Settings for CDTech_S035Q01 / LCD3 cape: */
+        lcd3 {
+                compatible = "ti,tilcdc,panel";
+                pinctrl-names = "default";
+                pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;
+                panel-info {
+                        ac-bias           = <255>;
+                        ac-bias-intrpt    = <0>;
+                        dma-burst-sz      = <16>;
+                        bpp               = <16>;
+                        fdd               = <0x80>;
+                        sync-edge         = <0>;
+                        sync-ctrl         = <1>;
+                        raster-order      = <0>;
+                        fifo-th           = <0>;
+                };
+                display-timings {
+                        native-mode = <&timing0>;
+                        timing0: 320x240 {
+                                hactive         = <320>;
+                                vactive         = <240>;
+                                hback-porch     = <21>;
+                                hfront-porch    = <58>;
+                                hsync-len       = <47>;
+                                vback-porch     = <11>;
+                                vfront-porch    = <23>;
+                                vsync-len       = <2>;
+                                clock-frequency = <8000000>;
+                                hsync-active    = <0>;
+                                vsync-active    = <0>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
new file mode 100644
index 000000000000..3d2c52460dca
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
@@ -0,0 +1,18 @@
+Device-Tree bindings for tilcdc DRM encoder slave output driver
+Required properties:
+ - compatible: value should be "ti,tilcdc,slave".
+ - i2c: the phandle for the i2c device the encoder slave is connected to
+Recommended properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure
+   muxing properly for pins that connect to TFP410 device
+Example:
+        hdmi {
+                compatible = "ti,tilcdc,slave";
+                i2c = <&i2c0>;
+                pinctrl-names = "default";
+                pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+        };
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt b/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
new file mode 100644
index 000000000000..a58ae7756fc6
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
@@ -0,0 +1,21 @@
+Device-Tree bindings for tilcdc DRM TFP410 output driver
+Required properties:
+ - compatible: value should be "ti,tilcdc,tfp410".
+ - i2c: the phandle for the i2c device to use for DDC
+Recommended properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure
+   muxing properly for pins that connect to TFP410 device
+ - powerdn-gpio: the powerdown GPIO, pulled low to power down the
+   TFP410 device (for DPMS_OFF)
+Example:
+        dvicape {
+                compatible = "ti,tilcdc,tfp410";
+                i2c = <&i2c2>;
+                pinctrl-names = "default";
+                pinctrl-0 = <&bone_dvi_cape_dvi_00A1_pins>;
+                powerdn-gpio = <&gpio2 31 0>;
+        };
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
new file mode 100644
index 000000000000..e5f130159ae1
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -0,0 +1,21 @@
+Device-Tree bindings for tilcdc DRM driver
+Required properties:
+ - compatible: value should be "ti,am33xx-tilcdc".
+ - interrupts: the interrupt number
+ - reg: base address and size of the LCDC device
+Recommended properties:
+ - interrupt-parent: the phandle for the interrupt controller that
+   services interrupts for this device.
+ - ti,hwmods: Name of the hwmod associated to the LCDC
+Example:
+        fb: fb@4830e000 {
+                compatible = "ti,am33xx-tilcdc";
+                reg = <0x4830e000 0x1000>;
+                interrupt-parent = <&intc>;
+                interrupts = <36>;
+                ti,hwmods = "lcdc";
+        };
diff --git a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
new file mode 100644
index 000000000000..e9de3756752b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
@@ -0,0 +1,20 @@
+Broadcom BCM2835 I2C controller
+Required properties:
+- compatible : Should be "brcm,bcm2835-i2c".
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks : The clock feeding the I2C controller.
+Recommended properties:
+- clock-frequency : desired I2C bus clock frequency in Hz.
+Example:
+i2c@20205000 {
+        compatible = "brcm,bcm2835-i2c";
+        reg = <0x7e205000 0x1000>;
+        interrupts = <2 21>;
+        clocks = <&clk_i2c>;
+        clock-frequency = <100000>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
index e9611ace8792..f98d4c5b5cca 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
@@ -8,6 +8,8 @@ Required properties:
      (b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c.
      (c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used
          inside HDMIPHY block found on several samsung SoCs
+      (d) "samsung, exynos5440-i2c", for s3c2440-like i2c used
+           on EXYNOS5440 which does not need GPIO configuration.
  - reg: physical base address of the controller and length of memory mapped
    region.
  - interrupts: interrupt number to the cpu.
diff --git a/Documentation/devicetree/bindings/i2c/ina209.txt b/Documentation/devicetree/bindings/i2c/ina209.txt
new file mode 100644
index 000000000000..9dd2bee80840
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ina209.txt
@@ -0,0 +1,18 @@
+ina209 properties
+Required properties:
+- compatible: Must be "ti,ina209"
+- reg: I2C address
+Optional properties:
+- shunt-resistor
+        Shunt resistor value in micro-Ohm
+Example:
+temp-sensor@4c {
+        compatible = "ti,ina209";
+        reg = <0x4c>;
+        shunt-resistor = <5000>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/max6697.txt b/Documentation/devicetree/bindings/i2c/max6697.txt
new file mode 100644
index 000000000000..5f793998e4a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/max6697.txt
@@ -0,0 +1,64 @@
+max6697 properties
+Required properties:
+- compatible:
+        Should be one of
+                maxim,max6581
+                maxim,max6602
+                maxim,max6622
+                maxim,max6636
+                maxim,max6689
+                maxim,max6693
+                maxim,max6694
+                maxim,max6697
+                maxim,max6698
+                maxim,max6699
+- reg: I2C address
+Optional properties:
+- smbus-timeout-disable
+        Set to disable SMBus timeout. If not specified, SMBus timeout will be
+        enabled.
+- extended-range-enable
+        Only valid for MAX6581. Set to enable extended temperature range.
+        Extended temperature will be disabled if not specified.
+- beta-compensation-enable
+        Only valid for MAX6693 and MX6694. Set to enable beta compensation on
+        remote temperature channel 1.
+        Beta compensation will be disabled if not specified.
+- alert-mask
+        Alert bit mask. Alert disabled for bits set.
+        Select bit 0 for local temperature, bit 1..7 for remote temperatures.
+        If not specified, alert will be enabled for all channels.
+- over-temperature-mask
+        Over-temperature bit mask. Over-temperature reporting disabled for
+        bits set.
+        Select bit 0 for local temperature, bit 1..7 for remote temperatures.
+        If not specified, over-temperature reporting will be enabled for all
+        channels.
+- resistance-cancellation
+        Boolean for all chips other than MAX6581. Set to enable resistance
+        cancellation on remote temperature channel 1.
+        For MAX6581, resistance cancellation enabled for all channels if
+        specified as boolean, otherwise as per bit mask specified.
+        Only supported for remote temperatures (bit 1..7).
+        If not specified, resistance cancellation will be disabled for all
+        channels.
+- transistor-ideality
+        For MAX6581 only. Two values; first is bit mask, second is ideality
+        select value as per MAX6581 data sheet. Select bit 1..7 for remote
+        channels.
+        Transistor ideality will be initialized to default (1.008) if not
+        specified.
+Example:
+temp-sensor@1a {
+        compatible = "maxim,max6697";
+        reg = <0x1a>;
+        smbus-timeout-disable;
+        resistance-cancellation;
+        alert-mask = <0x72>;
+        over-temperature-mask = <0x7f>;
+};
diff --git a/Documentation/devicetree/bindings/input/imx-keypad.txt b/Documentation/devicetree/bindings/input/imx-keypad.txt
new file mode 100644
index 000000000000..2ebaf7d26843
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/imx-keypad.txt
@@ -0,0 +1,53 @@
+* Freescale i.MX Keypad Port(KPP) device tree bindings
+The KPP is designed to interface with a keypad matrix with 2-point contact
+or 3-point contact keys. The KPP is designed to simplify the software task
+of scanning a keypad matrix. The KPP is capable of detecting, debouncing,
+and decoding one or multiple keys pressed simultaneously on a keypad.
+Required SoC Specific Properties:
+- compatible: Should be "fsl,<soc>-kpp".
+- reg: Physical base address of the KPP and length of memory mapped
+  region.
+- interrupts: The KPP interrupt number to the CPU(s).
+- clocks: The clock provided by the SoC to the KPP. Some SoCs use dummy
+clock(The clock for the KPP is provided by the SoCs automatically).
+Required Board Specific Properties:
+- pinctrl-names: The definition can be found at
+pinctrl/pinctrl-bindings.txt.
+- pinctrl-0: The definition can be found at
+pinctrl/pinctrl-bindings.txt.
+- linux,keymap: The definition can be found at
+bindings/input/matrix-keymap.txt.
+Example:
+kpp: kpp@73f94000 {
+        compatible = "fsl,imx51-kpp", "fsl,imx21-kpp";
+        reg = <0x73f94000 0x4000>;
+        interrupts = <60>;
+        clocks = <&clks 0>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&pinctrl_kpp_1>;
+        linux,keymap = <0x00000067      /* KEY_UP */
+                        0x0001006c      /* KEY_DOWN */
+                        0x00020072      /* KEY_VOLUMEDOWN */
+                        0x00030066      /* KEY_HOME */
+                        0x0100006a      /* KEY_RIGHT */
+                        0x01010069      /* KEY_LEFT */
+                        0x0102001c      /* KEY_ENTER */
+                        0x01030073      /* KEY_VOLUMEUP */
+                        0x02000040      /* KEY_F6 */
+                        0x02010042      /* KEY_F8 */
+                        0x02020043      /* KEY_F9 */
+                        0x02030044      /* KEY_F10 */
+                        0x0300003b      /* KEY_F1 */
+                        0x0301003c      /* KEY_F2 */
+                        0x0302003d      /* KEY_F3 */
+                        0x03030074>;    /* KEY_POWER */
+};
diff --git a/Documentation/devicetree/bindings/input/lpc32xx-key.txt b/Documentation/devicetree/bindings/input/lpc32xx-key.txt
index 31afd5014c48..bcf62f856358 100644
--- a/Documentation/devicetree/bindings/input/lpc32xx-key.txt
+++ b/Documentation/devicetree/bindings/input/lpc32xx-key.txt
@@ -1,19 +1,22 @@
 NXP LPC32xx Key Scan Interface
+This binding is based on the matrix-keymap binding with the following
+changes:
 Required Properties:
 - compatible: Should be "nxp,lpc3220-key"
 - reg: Physical base address of the controller and length of memory mapped
  region.
 - interrupts: The interrupt number to the cpu.
- keypad,num-rows: Number of rows and columns, e.g. 1: 1x1, 6: 6x6
- keypad,num-columns: Must be equal to keypad,num-rows since LPC32xx only
-  supports square matrices
 - nxp,debounce-delay-ms: Debounce delay in ms
 - nxp,scan-delay-ms: Repeated scan period in ms
 - linux,keymap: the key-code to be reported when the key is pressed
  and released, see also
  Documentation/devicetree/bindings/input/matrix-keymap.txt
+Note: keypad,num-rows and keypad,num-columns are required, and must be equal
+since LPC32xx only supports square matrices
 Example:
        key@40050000 {
diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt
index 3cd8b98ccd2d..c54919fad17e 100644
--- a/Documentation/devicetree/bindings/input/matrix-keymap.txt
+++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt
@@ -9,6 +9,12 @@ Required properties:
        row << 24 | column << 16 | key-code
 Optional properties:
+Properties for the number of rows and columns are optional because some
+drivers will use fixed values for these.
+- keypad,num-rows: Number of row lines connected to the keypad controller.
+- keypad,num-columns: Number of column lines connected to the keypad
+  controller.
 Some users of this binding might choose to specify secondary keymaps for
 cases where there is a modifier key such as a Fn key. Proposed names
 for said properties are "linux,fn-keymap" or with another descriptive
@@ -17,3 +23,5 @@ word for the modifier other from "Fn".
 Example:
        linux,keymap = < 0x00030012
                         0x0102003a >;
+        keypad,num-rows = <2>;
+        keypad,num-columns = <8>;
diff --git a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
index 72683be6de35..2995fae7ee47 100644
--- a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
+++ b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
@@ -1,7 +1,18 @@
 * Tegra keyboard controller
+The key controller has maximum 24 pins to make matrix keypad. Any pin
+can be configured as row or column. The maximum column pin can be 8
+and maximum row pins can be 16 for Tegra20/Tegra30.
 Required properties:
 - compatible: "nvidia,tegra20-kbc"
+- reg: Register base address of KBC.
+- interrupts: Interrupt number for the KBC.
+- nvidia,kbc-row-pins: The KBC pins which are configured as row. This is an
+  array of pin numbers which is used as rows.
+- nvidia,kbc-col-pins: The KBC pins which are configured as column. This is an
+  array of pin numbers which is used as column.
+- linux,keymap: The keymap for keys as described in the binding document
+  devicetree/bindings/input/matrix-keymap.txt.
 Optional properties, in addition to those specified by the shared
 matrix-keyboard bindings:
@@ -19,5 +30,16 @@ Example:
 keyboard: keyboard {
        compatible = "nvidia,tegra20-kbc";
        reg = <0x7000e200 0x100>;
+        interrupts = <0 85 0x04>;
        nvidia,ghost-filter;
+        nvidia,debounce-delay-ms = <640>;
+        nvidia,kbc-row-pins = <0 1 2>;    /* pin 0, 1, 2 as rows */
+        nvidia,kbc-col-pins = <11 12 13>; /* pin 11, 12, 13 as columns */
+        linux,keymap = <0x00000074
+                        0x00010067
+                        0x00020066
+                        0x01010068
+                        0x02000069
+                        0x02010070
+                        0x02020071>;
 };
diff --git a/Documentation/devicetree/bindings/input/omap-keypad.txt b/Documentation/devicetree/bindings/input/omap-keypad.txt
index f2fa5e10493d..34ed1c60ff95 100644
--- a/Documentation/devicetree/bindings/input/omap-keypad.txt
+++ b/Documentation/devicetree/bindings/input/omap-keypad.txt
@@ -6,19 +6,16 @@ A key can be placed at each intersection of a unique row and a unique column.
 The keypad controller can sense a key-press and key-release and report the
 event using a interrupt to the cpu.
+This binding is based on the matrix-keymap binding with the following
+changes:
+keypad,num-rows and keypad,num-columns are required.
 Required SoC Specific Properties:
 - compatible: should be one of the following
   - "ti,omap4-keypad": For controllers compatible with omap4 keypad
      controller.
-Required Board Specific Properties, in addition to those specified by
-the shared matrix-keyboard bindings:
- keypad,num-rows: Number of row lines connected to the keypad
-  controller.
- keypad,num-columns: Number of column lines connected to the
-  keypad controller.
 Optional Properties specific to linux:
 - linux,keypad-no-autorepeat: do no enable autorepeat feature.
diff --git a/Documentation/devicetree/bindings/input/tca8418_keypad.txt b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
index 2a1538f0053f..255185009167 100644
--- a/Documentation/devicetree/bindings/input/tca8418_keypad.txt
+++ b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
@@ -1,8 +1,10 @@
+This binding is based on the matrix-keymap binding with the following
+changes:
+keypad,num-rows and keypad,num-columns are required.
 Required properties:
 - compatible: "ti,tca8418"
 - reg: the I2C address
 - interrupts: IRQ line number, should trigger on falling edge
- keypad,num-rows: The number of rows
- keypad,num-columns: The number of columns
 - linux,keymap: Keys definitions, see keypad-matrix.
diff --git a/Documentation/devicetree/bindings/gpio/leds-ns2.txt b/Documentation/devicetree/bindings/leds/leds-ns2.txt
index aef3aca34d2d..aef3aca34d2d 100644
--- a/Documentation/devicetree/bindings/gpio/leds-ns2.txt
+++ b/Documentation/devicetree/bindings/leds/leds-ns2.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt b/Documentation/devicetree/bindings/leds/leds-pwm.txt
new file mode 100644
index 000000000000..7297107cf832
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt
@@ -0,0 +1,48 @@
+LED connected to PWM
+Required properties:
+- compatible : should be "pwm-leds".
+Each LED is represented as a sub-node of the pwm-leds device.  Each
+node's name represents the name of the corresponding LED.
+LED sub-node properties:
+- pwms : PWM property to point to the PWM device (phandle)/port (id) and to
+  specify the period time to be used: <&phandle id period_ns>;
+- pwm-names : (optional) Name to be used by the PWM subsystem for the PWM device
+  For the pwms and pwm-names property please refer to:
+  Documentation/devicetree/bindings/pwm/pwm.txt
+- max-brightness : Maximum brightness possible for the LED
+- label :  (optional)
+  see Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger :  (optional)
+  see Documentation/devicetree/bindings/leds/common.txt
+Example:
+twl_pwm: pwm {
+        /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
+        compatible = "ti,twl6030-pwm";
+        #pwm-cells = <2>;
+};
+twl_pwmled: pwmled {
+        /* provides one PWM (id 0 for Charing indicator LED) */
+        compatible = "ti,twl6030-pwmled";
+        #pwm-cells = <2>;
+};
+pwmleds {
+        compatible = "pwm-leds";
+        kpad {
+                label = "omap4::keypad";
+                pwms = <&twl_pwm 0 7812500>;
+                max-brightness = <127>;
+        };
+        charging {
+                label = "omap4:green:chrg";
+                pwms = <&twl_pwmled 0 7812500>;
+                max-brightness = <255>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/leds/tca6507.txt b/Documentation/devicetree/bindings/leds/tca6507.txt
new file mode 100644
index 000000000000..2b6693b972fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/tca6507.txt
@@ -0,0 +1,33 @@
+LEDs conected to tca6507
+Required properties:
+- compatible : should be : "ti,tca6507".
+Each led is represented as a sub-node of the ti,tca6507 device.
+LED sub-node properties:
+- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
+- reg : number of LED line (could be from 0 to 6)
+- linux,default-trigger : (optional)
+   see Documentation/devicetree/bindings/leds/common.txt
+Examples:
+tca6507@45 {
+        compatible = "ti,tca6507";
+        #address-cells = <1>;
+        #size-cells = <0>;
+        reg = <0x45>;
+        led0: red-aux@0 {
+                label = "red:aux";
+                reg = <0x0>;
+        };
+        led1: green-aux@1 {
+                label = "green:aux";
+                reg = <0x5>;
+                linux,default-trigger = "default-on";
+        };
+};
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
new file mode 100644
index 000000000000..56e726ef4bf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -0,0 +1,16 @@
+Device-Tree bindings for GPIO IR receiver
+Required properties:
+        - compatible: should be "gpio-ir-receiver".
+        - gpios: specifies GPIO used for IR signal reception.
+Optional properties:
+        - linux,rc-map-name: Linux specific remote control map name.
+Example node:
+        ir: ir-receiver {
+                compatible = "gpio-ir-receiver";
+                gpios = <&gpio0 19 1>;
+                linux,rc-map-name = "rc-rc6-mce";
+        };
diff --git a/Documentation/devicetree/bindings/mfd/max8925.txt b/Documentation/devicetree/bindings/mfd/max8925.txt
new file mode 100644
index 000000000000..4f0dc6638e5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max8925.txt
@@ -0,0 +1,64 @@
+* Maxim max8925 Power Management IC
+Required parent device properties:
+- compatible : "maxim,max8925"
+- reg : the I2C slave address for the max8925 chip
+- interrupts : IRQ line for the max8925 chip
+- interrupt-controller: describes the max8925 as an interrupt
+  controller (has its own domain)
+- #interrupt-cells : should be 1.
+        - The cell is the max8925 local IRQ number
+Optional parent device properties:
+- maxim,tsc-irq: there are 2 IRQ lines for max8925, one is indicated in
+  interrupts property, the other is indicated here.
+max8925 consists of a large and varied group of sub-devices:
+Device                   Supply Names    Description
+------                   ------------    -----------
+max8925-onkey           :               : On key
+max8925-rtc             :               : RTC
+max8925-regulator       :               : Regulators
+max8925-backlight       :               : Backlight
+max8925-touch           :               : Touchscreen
+max8925-power           :               : Charger
+Example:
+        pmic: max8925@3c {
+                compatible = "maxim,max8925";
+                reg = <0x3c>;
+                interrupts = <1>;
+                interrupt-parent = <&intcmux4>;
+                interrupt-controller;
+                #interrupt-cells = <1>;
+                maxim,tsc-irq = <0>;
+                regulators {
+                        SDV1 {
+                                regulator-min-microvolt = <637500>;
+                                regulator-max-microvolt = <1425000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                        LDO1 {
+                                regulator-min-microvolt = <750000>;
+                                regulator-max-microvolt = <3900000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                };
+                backlight {
+                        maxim,max8925-dual-string = <0>;
+                };
+                charger {
+                        batt-detect = <0>;
+                        topoff-threshold = <1>;
+                        fast-charge = <7>;
+                        no-temp-support = <0>;
+                        no-insert-detect = <0>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt b/Documentation/devicetree/bindings/mfd/tps6507x.txt
new file mode 100755
index 000000000000..8fffa3c5ed40
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt
@@ -0,0 +1,91 @@
+TPS6507x Power Management Integrated Circuit
+Required properties:
+- compatible: "ti,tps6507x"
+- reg: I2C slave address
+- regulators: This is the list of child nodes that specify the regulator
+  initialization data for defined regulators. Not all regulators for the
+  given device need to be present. The definition for each of these nodes
+  is defined using the standard binding for regulators found at
+  Documentation/devicetree/bindings/regulator/regulator.txt.
+  The regulator is matched with the regulator-compatible.
+  The valid regulator-compatible values are:
+  tps6507x: vdcdc1, vdcdc2, vdcdc3, vldo1, vldo2
+- xxx-supply: Input voltage supply regulator.
+  These entries are required if regulators are enabled for a device.
+  Missing of these properties can cause the regulator registration
+  fails.
+  If some of input supply is powered through battery or always-on
+  supply then also it is require to have these parameters with proper
+  node handle of always on power supply.
+  tps6507x:
+       vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
+       vindcdc3-supply  : VDCDC3 input.
+       vldo1_2-supply   : VLDO1 and VLDO2 input.
+Regulator Optional properties:
+- defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
+                        0: If defdcdc pin of DCDC2/DCDC3 is pulled to GND.
+                        1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
+  If this property is not defined, it defaults to 0 (not enabled).
+Example:
+        pmu: tps6507x@48 {
+                compatible = "ti,tps6507x";
+                reg = <0x48>;
+                vindcdc1_2-supply = <&vbat>;
+                vindcdc3-supply = <...>;
+                vinldo1_2-supply = <...>;
+                regulators {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        vdcdc1_reg: regulator@0 {
+                                regulator-compatible = "VDCDC1";
+                                reg = <0>;
+                                regulator-min-microvolt = <3150000>;
+                                regulator-max-microvolt = <3450000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                        };
+                        vdcdc2_reg: regulator@1 {
+                                regulator-compatible = "VDCDC2";
+                                reg = <1>;
+                                regulator-min-microvolt = <1710000>;
+                                regulator-max-microvolt = <3450000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                                defdcdc_default = <1>;
+                        };
+                        vdcdc3_reg: regulator@2 {
+                                regulator-compatible = "VDCDC3";
+                                reg = <2>;
+                                regulator-min-microvolt = <950000>
+                                regulator-max-microvolt = <1350000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                                defdcdc_default = <1>;
+                        };
+                        ldo1_reg: regulator@3 {
+                                regulator-compatible = "LDO1";
+                                reg = <3>;
+                                regulator-min-microvolt = <1710000>;
+                                regulator-max-microvolt = <1890000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                        };
+                        ldo2_reg: regulator@4 {
+                                regulator-compatible = "LDO2";
+                                reg = <4>;
+                                regulator-min-microvolt = <1140000>;
+                                regulator-max-microvolt = <1320000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt b/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt
index cb4291e3b1d1..a5bdff400002 100644
--- a/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt
+++ b/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt
@@ -1,7 +1,7 @@
 * DMA Engine.
 The Octeon DMA Engine transfers between the Boot Bus and main memory.
-The DMA Engine will be refered to by phandle by any device that is
+The DMA Engine will be referred to by phandle by any device that is
 connected to it.
 Properties:
diff --git a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
new file mode 100644
index 000000000000..59476fbdbfa1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
@@ -0,0 +1,18 @@
+Broadcom BCM2835 SDHCI controller
+This file documents differences between the core properties described
+by mmc.txt and the properties that represent the BCM2835 controller.
+Required properties:
+- compatible : Should be "brcm,bcm2835-sdhci".
+- clocks : The clock feeding the SDHCI controller.
+Example:
+sdhci: sdhci {
+        compatible = "brcm,bcm2835-sdhci";
+        reg = <0x7e300000 0x100>;
+        interrupts = <2 30>;
+        clocks = <&clk_mmc>;
+        bus-width = <4>;
+};
diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
index 792768953330..6d1c0988cfc7 100644
--- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -4,18 +4,18 @@
 The Synopsis designware mobile storage host controller is used to interface
 a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
 differences between the core Synopsis dw mshc controller properties described
-by synposis-dw-mshc.txt and the properties used by the Samsung Exynos specific
+by synopsis-dw-mshc.txt and the properties used by the Samsung Exynos specific
 extensions to the Synopsis Designware Mobile Storage Host Controller.
 Required Properties:
 * compatible: should be
        - "samsung,exynos4210-dw-mshc": for controllers with Samsung Exynos4210
-          specific extentions.
+          specific extensions.
        - "samsung,exynos4412-dw-mshc": for controllers with Samsung Exynos4412
-          specific extentions.
+          specific extensions.
        - "samsung,exynos5250-dw-mshc": for controllers with Samsung Exynos5250
-          specific extentions.
+          specific extensions.
 * samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
  unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index a591c6741d75..85aada2263d5 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -6,23 +6,45 @@ Interpreted by the OF core:
 - reg: Registers location and length.
 - interrupts: Interrupts used by the MMC controller.
-Required properties:
- bus-width: Number of data lines, can be <1>, <4>, or <8>
 Card detection:
-If no property below is supplied, standard SDHCI card detect is used.
+If no property below is supplied, host native card detect is used.
 Only one of the properties in this section should be supplied:
  - broken-cd: There is no card detection available; polling must be used.
  - cd-gpios: Specify GPIOs for card detection, see gpio binding
  - non-removable: non-removable slot (like eMMC); assume always present.
 Optional properties:
+- bus-width: Number of data lines, can be <1>, <4>, or <8>.  The default
+  will be <1> if the property is absent.
 - wp-gpios: Specify GPIOs for write protection, see gpio binding
- cd-inverted: when present, polarity on the cd gpio line is inverted
+- cd-inverted: when present, polarity on the CD line is inverted. See the note
- wp-inverted: when present, polarity on the wp gpio line is inverted
+  below for the case, when a GPIO is used for the CD line
+- wp-inverted: when present, polarity on the WP line is inverted. See the note
+  below for the case, when a GPIO is used for the WP line
 - max-frequency: maximum operating clock frequency
 - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
  this system, even if the controller claims it is.
+- cap-sd-highspeed: SD high-speed timing is supported
+- cap-mmc-highspeed: MMC high-speed timing is supported
+- cap-power-off-card: powering off the card is safe
+- cap-sdio-irq: enable SDIO IRQ signalling on this interface
+*NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
+polarity properties, we have to fix the meaning of the "normal" and "inverted"
+line levels. We choose to follow the SDHCI standard, which specifies both those
+lines as "active low." Therefore, using the "cd-inverted" property means, that
+the CD line is active high, i.e. it is high, when a card is inserted. Similar
+logic applies to the "wp-inverted" property.
+CD and WP lines can be implemented on the hardware in one of two ways: as GPIOs,
+specified in cd-gpios and wp-gpios properties, or as dedicated pins. Polarity of
+dedicated pins can be specified, using *-inverted properties. GPIO polarity can
+also be specified using the OF_GPIO_ACTIVE_LOW flag. This creates an ambiguity
+in the latter case. We choose to use the XOR logic for GPIO CD and WP lines.
+This means, the two properties are "superimposed," for example leaving the
+OF_GPIO_ACTIVE_LOW flag clear and specifying the respective *-inverted
+property results in a double-inversion and actually means the "normal" line
+polarity is in effect.
 Optional SDIO properties:
 - keep-power-in-suspend: Preserves card power during a suspend/resume cycle
diff --git a/Documentation/devicetree/bindings/mmc/orion-sdio.txt b/Documentation/devicetree/bindings/mmc/orion-sdio.txt
new file mode 100644
index 000000000000..84f0ebd67a13
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/orion-sdio.txt
@@ -0,0 +1,17 @@
+* Marvell orion-sdio controller
+This file documents differences between the core properties in mmc.txt
+and the properties used by the orion-sdio driver.
+- compatible: Should be "marvell,orion-sdio"
+- clocks: reference to the clock of the SDIO interface
+Example:
+        mvsdio@d00d4000 {
+                compatible = "marvell,orion-sdio";
+                reg = <0xd00d4000 0x200>;
+                interrupts = <54>;
+                clocks = <&gateclk 17>;
+                status = "disabled";
+        };
diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
index 97e9e315400d..3b3a1ee055ff 100644
--- a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -55,5 +55,5 @@ Example:
        };
        Note: This example shows both SoC specific and board specific properties
-        in a single device node. The properties can be actually be seperated
+        in a single device node. The properties can be actually be separated
        into SoC specific node and board specific node.
diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
index 06cd32d08052..726fd2122a13 100644
--- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
@@ -26,8 +26,16 @@ Required Properties:
        * bus-width: as documented in mmc core bindings.
        * wp-gpios: specifies the write protect gpio line. The format of the
-          gpio specifier depends on the gpio controller. If the write-protect
+          gpio specifier depends on the gpio controller. If a GPIO is not used
-          line is not available, this property is optional.
+          for write-protect, this property is optional.
+        * disable-wp: If the wp-gpios property isn't present then (by default)
+          we'd assume that the write protect is hooked up directly to the
+          controller's special purpose write protect line (accessible via
+          the WRTPRT register).  However, it's possible that we simply don't
+          want write protect.  In that case specify 'disable-wp'.
+          NOTE: This property is not required for slots known to always
+          connect to eMMC or SDIO cards.
 Optional properties:
diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
new file mode 100644
index 000000000000..df204e18e030
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -0,0 +1,20 @@
+* Toshiba Mobile IO SD/MMC controller
+The tmio-mmc driver doesn't probe its devices actively, instead its binding to
+devices is managed by either MFD drivers or by the sh_mobile_sdhi platform
+driver. Those drivers supply the tmio-mmc driver with platform data, that either
+describe hardware capabilities, known to them, or are obtained by them from
+their own platform data or from their DT information. In the latter case all
+compulsory and any optional properties, common to all SD/MMC drivers, as
+described in mmc.txt, can be used. Additionally the following tmio_mmc-specific
+optional bindings can be used.
+Optional properties:
+- toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
+When used with Renesas SDHI hardware, the following compatibility strings
+configure various model-specific properties:
+"renesas,sh7372-sdhi":  (default) compatible with SH7372
+"renesas,r8a7740-sdhi": compatible with R8A7740: certain MMC/SD commands have to
+                        wait for the interface to become idle.
diff --git a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
index e3ea32e7de3e..2240ac09f6ba 100644
--- a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
@@ -1,7 +1,7 @@
 * FSMC NAND
 Required properties:
- compatible : "st,spear600-fsmc-nand"
+- compatible : "st,spear600-fsmc-nand", "stericsson,fsmc-nand"
 - reg : Address range of the mtd chip
 - reg-names: Should contain the reg names "fsmc_regs", "nand_data", "nand_addr" and "nand_cmd"
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
new file mode 100644
index 000000000000..e7f8d7ed47eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,80 @@
+Device tree bindings for GPMC connected NANDs
+GPMC connected NAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of "nand".
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+For NAND specific properties such as ECC modes or bus width, please refer to
+Documentation/devicetree/bindings/mtd/nand.txt
+Required properties:
+ - reg:         The CS line the peripheral is connected to
+Optional properties:
+ - nand-bus-width:              Set this numeric value to 16 if the hardware
+                                is wired that way. If not specified, a bus
+                                width of 8 is assumed.
+ - ti,nand-ecc-opt:             A string setting the ECC layout to use. One of:
+                "sw"            Software method (default)
+                "hw"            Hardware method
+                "hw-romcode"    gpmc hamming mode method & romcode layout
+                "bch4"          4-bit BCH ecc code
+                "bch8"          8-bit BCH ecc code
+ - elm_id:      Specifies elm device node. This is required to support BCH
+                error correction using ELM module.
+For inline partiton table parsing (optional):
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+Example for an AM33xx board:
+        gpmc: gpmc@50000000 {
+                compatible = "ti,am3352-gpmc";
+                ti,hwmods = "gpmc";
+                reg = <0x50000000 0x1000000>;
+                interrupts = <100>;
+                gpmc,num-cs = <8>;
+                gpmc,num-waitpins = <2>;
+                #address-cells = <2>;
+                #size-cells = <1>;
+                ranges = <0 0 0x08000000 0x2000>;       /* CS0: NAND */
+                elm_id = <&elm>;
+                nand@0,0 {
+                        reg = <0 0 0>; /* CS0, offset 0 */
+                        nand-bus-width = <16>;
+                        ti,nand-ecc-opt = "bch8";
+                        gpmc,sync-clk = <0>;
+                        gpmc,cs-on = <0>;
+                        gpmc,cs-rd-off = <44>;
+                        gpmc,cs-wr-off = <44>;
+                        gpmc,adv-on = <6>;
+                        gpmc,adv-rd-off = <34>;
+                        gpmc,adv-wr-off = <44>;
+                        gpmc,we-off = <40>;
+                        gpmc,oe-off = <54>;
+                        gpmc,access = <64>;
+                        gpmc,rd-cycle = <82>;
+                        gpmc,wr-cycle = <82>;
+                        gpmc,wr-access = <40>;
+                        gpmc,wr-data-mux-bus = <0>;
+                        #address-cells = <1>;
+                        #size-cells = <1>;
+                        /* partitions go here */
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
new file mode 100644
index 000000000000..deec9da224a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -0,0 +1,43 @@
+Device tree bindings for GPMC connected OneNANDs
+GPMC connected OneNAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of "onenand".
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+Required properties:
+ - reg:                 The CS line the peripheral is connected to
+Optional properties:
+ - dma-channel:         DMA Channel index
+For inline partiton table parsing (optional):
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+Example for an OMAP3430 board:
+        gpmc: gpmc@6e000000 {
+                compatible = "ti,omap3430-gpmc";
+                ti,hwmods = "gpmc";
+                reg = <0x6e000000 0x1000000>;
+                interrupts = <20>;
+                gpmc,num-cs = <8>;
+                gpmc,num-waitpins = <4>;
+                #address-cells = <2>;
+                #size-cells = <1>;
+                onenand@0 {
+                        reg = <0 0 0>; /* CS0, offset 0 */
+                        #address-cells = <1>;
+                        #size-cells = <1>;
+                        /* partitions go here */
+                };
+        };
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd0286a9b7..ecfdf756d10f 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -24,6 +24,8 @@ Required properties:
 Optional properties:
 - ti,hwmods             : Must be "cpgmac0"
 - no_bd_ram             : Must be 0 or 1
+- dual_emac             : Specifies Switch to act as Dual EMAC
+- dual_emac_res_vlan    : Specifies VID to be used to segregate the ports
 Note: "ti,hwmods" field is used to fetch the base address and irq
 resources from TI, omap hwmod data base during device registration.
diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
new file mode 100644
index 000000000000..dff0e5f995e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -0,0 +1,60 @@
+* Allwinner A1X Pin Controller
+The pins controlled by sunXi pin controller are organized in banks,
+each bank has 32 pins.  Each pin has 7 multiplexing functions, with
+the first two functions being GPIO in and out. The configuration on
+the pins includes drive strength and pull-up.
+Required properties:
+- compatible: "allwinner,<soc>-pinctrl". Supported SoCs for now are:
+  sun5i-a13.
+- reg: Should contain the register physical address and length for the
+  pin controller.
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+A pinctrl node should contain at least one subnodes representing the
+pinctrl groups available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, drive strength and pullups. If one of these options is
+not set, its actual value will be unspecified.
+Required subnode-properties:
+- allwinner,pins: List of strings containing the pin name.
+- allwinner,function: Function to mux the pins listed above to.
+Optional subnode-properties:
+- allwinner,drive: Integer. Represents the current sent to the pin
+    0: 10 mA
+    1: 20 mA
+    2: 30 mA
+    3: 40 mA
+- allwinner,pull: Integer.
+    0: No resistor
+    1: Pull-up resistor
+    2: Pull-down resistor
+Examples:
+pinctrl@01c20800 {
+        compatible = "allwinner,sun5i-a13-pinctrl";
+        reg = <0x01c20800 0x400>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        uart1_pins_a: uart1@0 {
+                allwinner,pins = "PE10", "PE11";
+                allwinner,function = "uart1";
+                allwinner,drive = <0>;
+                allwinner,pull = <0>;
+        };
+        uart1_pins_b: uart1@1 {
+                allwinner,pins = "PG3", "PG4";
+                allwinner,function = "uart1";
+                allwinner,drive = <0>;
+                allwinner,pull = <0>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
index 3a268127b054..bc50899e0c81 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
@@ -81,7 +81,8 @@ PA31	TXD4
 Required properties for pin configuration node:
 - atmel,pins: 4 integers array, represents a group of pins mux and config
  setting. The format is atmel,pins = <PIN_BANK PIN_BANK_NUM PERIPH CONFIG>.
-  The PERIPH 0 means gpio.
+  The PERIPH 0 means gpio, PERIPH 1 is periph A, PERIPH 2 is periph B...
+  PIN_BANK 0 is pioA, PIN_BANK 1 is pioB...
 Bits used for CONFIG:
 PULL_UP         (1 << 0): indicate this pin need a pull up.
@@ -126,7 +127,7 @@ pinctrl@fffff400 {
                pinctrl_dbgu: dbgu-0 {
                        atmel,pins =
                                <1 14 0x1 0x0   /* PB14 periph A */
-                                 1 15 0x1 0x1>; /* PB15 periph with pullup */
+                                 1 15 0x1 0x1>; /* PB15 periph A with pullup */
                };
        };
 };
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt
new file mode 100644
index 000000000000..e204d009f16c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt
@@ -0,0 +1,120 @@
+NVIDIA Tegra114 pinmux controller
+The Tegra114 pinctrl binding is very similar to the Tegra20 and Tegra30
+pinctrl binding, as described in nvidia,tegra20-pinmux.txt and
+nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as
+a baseline, and only documents the differences between the two bindings.
+Required properties:
+- compatible: "nvidia,tegra114-pinmux"
+- reg: Should contain the register physical address and length for each of
+  the pad control and mux registers. The first bank of address must be the
+  driver strength pad control register address and second bank address must
+  be pinmux register address.
+Tegra114 adds the following optional properties for pin configuration subnodes:
+- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes.
+- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes.
+- nvidia,lock: Integer. Lock the pin configuration against further changes
+    until reset. 0: no, 1: yes.
+- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes.
+- nvidia,rcv-sel: Integer. Select VIL/VIH receivers. 0: normal, 1: high.
+- nvidia,drive-type: Integer. Valid range 0...3.
+As with Tegra20 and Terga30, see the Tegra TRM for complete details regarding
+which groups support which functionality.
+Valid values for pin and group names are:
+  per-pin mux groups:
+    These all support nvidia,function, nvidia,tristate, nvidia,pull,
+    nvidia,enable-input, nvidia,lock. Some support nvidia,open-drain,
+    nvidia,io-reset and nvidia,rcv-sel.
+    ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4,
+    ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0,
+    ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0,
+    dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0,
+    sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6,
+    sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4,
+    ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6,
+    uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1,
+    uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_sda_pc5,
+    gen1_i2c_scl_pc4, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7,
+    clk3_out_pee0, clk3_req_pee1, gmi_wp_n_pc7, gmi_iordy_pi5, gmi_wait_pi7,
+    gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs0_n_pj0, gmi_cs1_n_pj2, gmi_cs2_n_pk3,
+    gmi_cs3_n_pk4, gmi_cs4_n_pk2, gmi_cs6_n_pi3, gmi_cs7_n_pi6, gmi_ad0_pg0,
+    gmi_ad1_pg1, gmi_ad2_pg2, gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5,
+    gmi_ad6_pg6, gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2,
+    gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, gmi_ad15_ph7,
+    gmi_a16_pj7, gmi_a17_pb0, gmi_a18_pb1, gmi_a19_pk7, gmi_wr_n_pi0,
+    gmi_oe_n_pi1, gmi_dqs_p_pj3, gmi_rst_n_pi4, gen2_i2c_scl_pt5,
+    gen2_i2c_sda_pt6, sdmmc4_clk_pcc4, sdmmc4_cmd_pt7, sdmmc4_dat0_paa0,
+    sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4,
+    sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, cam_mclk_pcc0,
+    pcc1, pbb0, cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6,
+    pbb7, pcc2, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1,
+    kb_row2_pr2, kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6,
+    kb_row7_pr7, kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_col0_pq0,
+    kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5,
+    kb_col6_pq6, kb_col7_pq7, clk_32k_out_pa0, sys_clk_req_pz5, core_pwr_req,
+    cpu_pwr_req, pwr_int_n, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2,
+    dap1_sclk_pn3, clk1_req_pee2, clk1_out_pw4, spdif_in_pk6, spdif_out_pk5,
+    dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3, dvfs_pwm_px0,
+    gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2, gpio_x4_aud_px4,
+    gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7, sdmmc3_clk_pa6,
+    sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, sdmmc3_dat2_pb5,
+    sdmmc3_dat3_pb4, hdmi_cec_pee3, sdmmc1_wp_n_pv3, sdmmc3_cd_n_pv2,
+    gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4, usb_vbus_en1_pn5,
+    sdmmc3_clk_lb_in_pee5, sdmmc3_clk_lb_out_pee4, reset_out_n.
+  drive groups:
+    These all support nvidia,pull-down-strength, nvidia,pull-up-strength,
+    nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all
+    support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode
+    and nvidia,drive-type.
+    ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, dap1, dap2, dap3, dap4,
+    dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg,
+    gmh, owr, uda.
+Example:
+        pinmux: pinmux {
+                compatible = "nvidia,tegra114-pinmux";
+                reg = <0x70000868 0x148         /* Pad control registers */
+                       0x70003000 0x40c>;       /* PinMux registers */
+        };
+Example board file extract:
+        pinctrl {
+                sdmmc4_default: pinmux {
+                        sdmmc4_clk_pcc4 {
+                                nvidia,pins = "sdmmc4_clk_pcc4",
+                                nvidia,function = "sdmmc4";
+                                nvidia,pull = <0>;
+                                nvidia,tristate = <0>;
+                        };
+                        sdmmc4_dat0_paa0 {
+                                nvidia,pins = "sdmmc4_dat0_paa0",
+                                                "sdmmc4_dat1_paa1",
+                                                "sdmmc4_dat2_paa2",
+                                                "sdmmc4_dat3_paa3",
+                                                "sdmmc4_dat4_paa4",
+                                                "sdmmc4_dat5_paa5",
+                                                "sdmmc4_dat6_paa6",
+                                                "sdmmc4_dat7_paa7";
+                                nvidia,function = "sdmmc4";
+                                nvidia,pull = <2>;
+                                nvidia,tristate = <0>;
+                        };
+                };
+        };
+        sdhci@78000400 {
+                pinctrl-names = "default";
+                pinctrl-0 = <&sdmmc4_default>;
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index e97a27856b21..4598a47aa0cd 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -7,9 +7,9 @@ on-chip controllers onto these pads.
 Required Properties:
 - compatible: should be one of the following.
-  - "samsung,pinctrl-exynos4210": for Exynos4210 compatible pin-controller.
+  - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
-  - "samsung,pinctrl-exynos4x12": for Exynos4x12 compatible pin-controller.
+  - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
-  - "samsung,pinctrl-exynos5250": for Exynos5250 compatible pin-controller.
+  - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller.
 - reg: Base address of the pin controller hardware module and length of
  the address space it occupies.
@@ -142,7 +142,7 @@ the following format 'pinctrl{n}' where n is a unique number for the alias.
 Example: A pin-controller node with pin banks:
        pinctrl_0: pinctrl@11400000 {
-                compatible = "samsung,pinctrl-exynos4210";
+                compatible = "samsung,exynos4210-pinctrl";
                reg = <0x11400000 0x1000>;
                interrupts = <0 47 0>;
@@ -185,7 +185,7 @@ Example: A pin-controller node with pin banks:
 Example 1: A pin-controller node with pin groups.
        pinctrl_0: pinctrl@11400000 {
-                compatible = "samsung,pinctrl-exynos4210";
+                compatible = "samsung,exynos4210-pinctrl";
                reg = <0x11400000 0x1000>;
                interrupts = <0 47 0>;
@@ -230,7 +230,7 @@ Example 1: A pin-controller node with pin groups.
 Example 2: A pin-controller node with external wakeup interrupt controller node.
        pinctrl_1: pinctrl@11000000 {
-                compatible = "samsung,pinctrl-exynos4210";
+                compatible = "samsung,exynos4210-pinctrl";
                reg = <0x11000000 0x1000>;
                interrupts = <0 46 0>
diff --git a/Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt b/Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt
new file mode 100644
index 000000000000..9a2f3f420526
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt
@@ -0,0 +1,140 @@
+ST Ericsson Nomadik pinmux controller
+Required properties:
+- compatible: "stericsson,nmk-pinctrl", "stericsson,nmk-pinctrl-db8540",
+              "stericsson,nmk-pinctrl-stn8815"
+- reg: Should contain the register physical address and length of the PRCMU.
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+ST Ericsson's pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as input, output, pull up, pull down...
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+Required subnode-properties:
+- ste,pins : An array of strings. Each string contains the name of a pin or
+    group.
+Optional subnode-properties:
+- ste,function: A string containing the name of the function to mux to the
+  pin or group.
+- ste,config: Handle of pin configuration node (e.g. ste,config = <&slpm_in_wkup_pdis>)
+- ste,input : <0/1/2>
+        0: input with no pull
+        1: input with pull up,
+        2: input with pull down,
+- ste,output: <0/1/2>
+        0: output low,
+        1: output high,
+        2: output (value is not specified).
+- ste,sleep: <0/1>
+        0: sleep mode disable,
+        1: sleep mode enable.
+- ste,sleep-input: <0/1/2/3>
+        0: sleep input with no pull,
+        1: sleep input with pull up,
+        2: sleep input with pull down.
+        3: sleep input and keep last input configuration (no pull, pull up or pull down).
+- ste,sleep-output: <0/1/2>
+        0: sleep output low,
+        1: sleep output high,
+        2: sleep output (value is not specified).
+- ste,sleep-gpio: <0/1>
+        0: disable sleep gpio mode,
+        1: enable sleep gpio mode.
+- ste,sleep-wakeup: <0/1>
+        0: wake-up detection enabled,
+        1: wake-up detection disabled.
+- ste,sleep-pull-disable: <0/1>
+        0: GPIO pull-up or pull-down resistor is enabled, when pin is an input,
+        1: GPIO pull-up and pull-down resistor are disabled.
+Example board file extract:
+        pinctrl@80157000 {
+                compatible = "stericsson,nmk-pinctrl";
+                reg = <0x80157000 0x2000>;
+                pinctrl-names = "default";
+                slpm_in_wkup_pdis: slpm_in_wkup_pdis {
+                        ste,sleep = <1>;
+                        ste,sleep-input = <3>;
+                        ste,sleep-wakeup = <1>;
+                        ste,sleep-pull-disable = <0>;
+                };
+                slpm_out_hi_wkup_pdis: slpm_out_hi_wkup_pdis {
+                        ste,sleep = <1>;
+                        ste,sleep-output = <1>;
+                        ste,sleep-wakeup = <1>;
+                        ste,sleep-pull-disable = <0>;
+                };
+                slpm_out_wkup_pdis: slpm_out_wkup_pdis {
+                        ste,sleep = <1>;
+                        ste,sleep-output = <2>;
+                        ste,sleep-wakeup = <1>;
+                        ste,sleep-pull-disable = <0>;
+                };
+                uart0 {
+                        uart0_default_mux: uart0_mux {
+                                u0_default_mux {
+                                        ste,function = "u0";
+                                        ste,pins = "u0_a_1";
+                                };
+                        };
+                        uart0_default_mode: uart0_default {
+                                uart0_default_cfg1 {
+                                        ste,pins = "GPIO0", "GPIO2";
+                                        ste,input = <1>;
+                                };
+                                uart0_default_cfg2 {
+                                        ste,pins = "GPIO1", "GPIO3";
+                                        ste,output = <1>;
+                                };
+                        };
+                        uart0_sleep_mode: uart0_sleep {
+                                uart0_sleep_cfg1 {
+                                        ste,pins = "GPIO0", "GPIO2";
+                                        ste,config = <&slpm_in_wkup_pdis>;
+                                };
+                                uart0_sleep_cfg2 {
+                                        ste,pins = "GPIO1";
+                                        ste,config = <&slpm_out_hi_wkup_pdis>;
+                                };
+                                uart0_sleep_cfg3 {
+                                        ste,pins = "GPIO3";
+                                        ste,config = <&slpm_out_wkup_pdis>;
+                                };
+                        };
+                };
+        };
+        uart@80120000 {
+                compatible = "arm,pl011", "arm,primecell";
+                reg = <0x80120000 0x1000>;
+                interrupts = <0 11 0x4>;
+                pinctrl-names = "default","sleep";
+                pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
+                pinctrl-1 = <&uart0_sleep_mode>;
+        };
diff --git a/Documentation/devicetree/bindings/power_supply/max8925_batter.txt b/Documentation/devicetree/bindings/power_supply/max8925_batter.txt
new file mode 100644
index 000000000000..d7e3e0c0f71d
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/max8925_batter.txt
@@ -0,0 +1,18 @@
+max8925-battery bindings
+~~~~~~~~~~~~~~~~
+Optional properties :
+ - batt-detect: whether support battery detect
+ - topoff-threshold: set charging current in topoff mode
+ - fast-charge: set charging current in fast mode
+ - no-temp-support: whether support temperature protection detect
+ - no-insert-detect: whether support insert detect
+Example:
+        charger {
+                batt-detect = <0>;
+                topoff-threshold = <1>;
+                fast-charge = <7>;
+                no-temp-support = <0>;
+                no-insert-detect = <0>;
+        };
diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
new file mode 100644
index 000000000000..9a599d27bd75
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
@@ -0,0 +1,13 @@
+* QNAP Power Off
+QNAP NAS devices have a microcontroller controlling the main power
+supply. This microcontroller is connected to UART1 of the Kirkwood and
+Orion5x SoCs. Sending the charactor 'A', at 19200 baud, tells the
+microcontroller to turn the power off. This driver adds a handler to
+pm_power_off which is called to turn the power off.
+Required Properties:
+- compatible: Should be "qnap,power-off"
+- reg: Address and length of the register set for UART1
+- clocks: tclk clock
diff --git a/Documentation/devicetree/bindings/power_supply/restart-poweroff.txt b/Documentation/devicetree/bindings/power_supply/restart-poweroff.txt
new file mode 100644
index 000000000000..5776e684afda
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/restart-poweroff.txt
@@ -0,0 +1,8 @@
+* Restart Power Off
+Buffalo Linkstation LS-XHL and LS-CHLv2, and other devices power off
+by restarting and letting u-boot keep hold of the machine until the
+user presses a button.
+Required Properties:
+- compatible: Should be "restart-poweroff"
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
index 9e7a2417dac5..7f150b5012cc 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
@@ -17,9 +17,20 @@ Recommended properties:
   contains a functioning "reset control register" (i.e. the board
   is wired to reset upon setting the HRESET_REQ bit in this register).
-Example:
+ - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
+   registers, for those SOCs that have a PAMU device.
+Examples:
        global-utilities@e0000 {        /* global utilities block */
                compatible = "fsl,mpc8548-guts";
                reg = <e0000 1000>;
                fsl,has-rstcr;
        };
+        guts: global-utilities@e0000 {
+                compatible = "fsl,qoriq-device-config-1.0";
+                reg = <0xe0000 0xe00>;
+                fsl,has-rstcr;
+                #sleep-cells = <1>;
+                fsl,liodn-bits = <12>;
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
new file mode 100644
index 000000000000..1f5e329f756c
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
@@ -0,0 +1,140 @@
+Freescale Peripheral Management Access Unit (PAMU) Device Tree Binding
+DESCRIPTION
+The PAMU is an I/O MMU that provides device-to-memory access control and
+address translation capabilities.
+Required properties:
+- compatible    : <string>
+                  First entry is a version-specific string, such as
+                  "fsl,pamu-v1.0".  The second is "fsl,pamu".
+- ranges        : <prop-encoded-array>
+                  A standard property. Utilized to describe the memory mapped
+                  I/O space utilized by the controller.  The size should
+                  be set to the total size of the register space of all
+                  physically present PAMU controllers.  For example, for
+                  PAMU v1.0, on an SOC that has five PAMU devices, the size
+                  is 0x5000.
+- interrupts    : <prop-encoded-array>
+                  Interrupt mappings.  The first tuple is the normal PAMU
+                  interrupt, used for reporting access violations.  The second
+                  is for PAMU hardware errors, such as PAMU operation errors
+                  and ECC errors.
+- #address-cells: <u32>
+                  A standard property.
+- #size-cells   : <u32>
+                  A standard property.
+Optional properties:
+- reg           : <prop-encoded-array>
+                  A standard property.   It represents the CCSR registers of
+                  all child PAMUs combined.  Include it to provide support
+                  for legacy drivers.
+- interrupt-parent : <phandle>
+                  Phandle to interrupt controller
+Child nodes:
+Each child node represents one PAMU controller.  Each SOC device that is
+connected to a specific PAMU device should have a "fsl,pamu-phandle" property
+that links to the corresponding specific child PAMU controller.
+- reg           : <prop-encoded-array>
+                  A standard property.  Specifies the physical address and
+                  length (relative to the parent 'ranges' property) of this
+                  PAMU controller's configuration registers.  The size should
+                  be set to the size of this PAMU controllers's register space.
+                  For PAMU v1.0, this size is 0x1000.
+- fsl,primary-cache-geometry
+                : <prop-encoded-array>
+                  Two cells that specify the geometry of the primary PAMU
+                  cache.  The first is the number of cache lines, and the
+                  second is the number of "ways".  For direct-mapped caches,
+                  specify a value of 1.
+- fsl,secondary-cache-geometry
+                : <prop-encoded-array>
+                  Two cells that specify the geometry of the secondary PAMU
+                  cache.  The first is the number of cache lines, and the
+                  second is the number of "ways".  For direct-mapped caches,
+                  specify a value of 1.
+Device nodes:
+Devices that have LIODNs need to specify links to the parent PAMU controller
+(the actual PAMU controller that this device is connected to) and a pointer to
+the LIODN register, if applicable.
+- fsl,iommu-parent
+                : <phandle>
+                Phandle to the single, specific PAMU controller node to which
+                this device is connect.  The PAMU topology is represented in
+                the device tree to assist code that dynamically determines the
+                best LIODN values to minimize PAMU cache thrashing.
+- fsl,liodn-reg : <prop-encoded-array>
+                  Two cells that specify the location of the LIODN register
+                  for this device.  Required for devices that have a single
+                  LIODN.  The first cell is a phandle to a node that contains
+                  the registers where the LIODN is to be set.  The second is
+                  the offset from the first "reg" resource of the node where
+                  the specific LIODN register is located.
+Example:
+        iommu@20000 {
+                compatible = "fsl,pamu-v1.0", "fsl,pamu";
+                reg = <0x20000 0x5000>;
+                ranges = <0 0x20000 0x5000>;
+                #address-cells = <1>;
+                #size-cells = <1>;
+                interrupts = <
+                        24 2 0 0
+                        16 2 1 30>;
+                pamu0: pamu@0 {
+                        reg = <0 0x1000>;
+                        fsl,primary-cache-geometry = <32 1>;
+                        fsl,secondary-cache-geometry = <128 2>;
+                };
+                pamu1: pamu@1000 {
+                        reg = <0x1000 0x1000>;
+                        fsl,primary-cache-geometry = <32 1>;
+                        fsl,secondary-cache-geometry = <128 2>;
+                };
+                pamu2: pamu@2000 {
+                        reg = <0x2000 0x1000>;
+                        fsl,primary-cache-geometry = <32 1>;
+                        fsl,secondary-cache-geometry = <128 2>;
+                };
+                pamu3: pamu@3000 {
+                        reg = <0x3000 0x1000>;
+                        fsl,primary-cache-geometry = <32 1>;
+                        fsl,secondary-cache-geometry = <128 2>;
+                };
+                pamu4: pamu@4000 {
+                        reg = <0x4000 0x1000>;
+                        fsl,primary-cache-geometry = <32 1>;
+                        fsl,secondary-cache-geometry = <128 2>;
+                };
+        };
+        guts: global-utilities@e0000 {
+                compatible = "fsl,qoriq-device-config-1.0";
+                reg = <0xe0000 0xe00>;
+                fsl,has-rstcr;
+                #sleep-cells = <1>;
+                fsl,liodn-bits = <12>;
+        };
+/include/ "qoriq-dma-0.dtsi"
+        dma@100300 {
+                fsl,iommu-parent = <&pamu0>;
+                fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/srio.txt b/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
index b039bcbee134..07abf0f2f440 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
@@ -8,9 +8,9 @@ Properties:
        Definition: Must include "fsl,srio" for IP blocks with IP Block
        Revision Register (SRIO IPBRR1) Major ID equal to 0x01c0.
-        Optionally, a compatiable string of "fsl,srio-vX.Y" where X is Major
+        Optionally, a compatible string of "fsl,srio-vX.Y" where X is Major
        version in IP Block Revision Register and Y is Minor version.  If this
-        compatiable is provided it should be ordered before "fsl,srio".
+        compatible is provided it should be ordered before "fsl,srio".
   - reg
        Usage: required
diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
new file mode 100644
index 000000000000..de0eaed86651
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
@@ -0,0 +1,18 @@
+Atmel TCB PWM controller
+Required properties:
+- compatible: should be "atmel,tcb-pwm"
+- #pwm-cells: Should be 3.  The first cell specifies the per-chip index
+  of the PWM to use, the second cell is the period in nanoseconds and
+  bit 0 in the third cell is used to encode the polarity of PWM output.
+  Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity &
+  set to 0 for normal polarity.
+- tc-block: The Timer Counter block to use as a PWM chip.
+Example:
+pwm {
+        compatible = "atmel,tcb-pwm";
+        #pwm-cells = <3>;
+        tc-block = <1>;
+};
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
index bcc63678a9a5..d21d82d29855 100644
--- a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -3,14 +3,17 @@ VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
 Required properties:
 - compatible: should be "via,vt8500-pwm"
 - reg: physical base address and length of the controller's registers
- #pwm-cells: should be 2.  The first cell specifies the per-chip index
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
-  of the PWM to use and the second cell is the period in nanoseconds.
+  First cell specifies the per-chip index of the PWM to use, the second
+  cell is the period in nanoseconds and bit 0 in the third cell is used to
+  encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
+  to 1 for inverse polarity & set to 0 for normal polarity.
 - clocks: phandle to the PWM source clock
 Example:
 pwm1: pwm@d8220000 {
-        #pwm-cells = <2>;
+        #pwm-cells = <3>;
        compatible = "via,vt8500-pwm";
        reg = <0xd8220000 0x1000>;
        clocks = <&clkpwm>;
diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
index 357758cb6e92..758eae24082a 100644
--- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
@@ -9,6 +9,11 @@ Required properties:
 - anatop-min-voltage: Minimum voltage of this regulator
 - anatop-max-voltage: Maximum voltage of this regulator
+Optional properties:
+- anatop-delay-reg-offset: Anatop MFD step time register offset
+- anatop-delay-bit-shift: Bit shift for the step time register
+- anatop-delay-bit-width: Number of bits used in the step time register
 Any property defined as part of the core regulator
 binding, defined in regulator.txt, can also be used.
@@ -23,6 +28,9 @@ Example:
                anatop-reg-offset = <0x140>;
                anatop-vol-bit-shift = <9>;
                anatop-vol-bit-width = <5>;
+                anatop-delay-reg-offset = <0x170>;
+                anatop-delay-bit-shift = <24>;
+                anatop-delay-bit-width = <2>;
                anatop-min-bit-val = <1>;
                anatop-min-voltage = <725000>;
                anatop-max-voltage = <1300000>;
diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
new file mode 100644
index 000000000000..a35ff99003a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
@@ -0,0 +1,152 @@
+* Samsung S5M8767 Voltage and Current Regulator
+The Samsung S5M8767 is a multi-function device which includes volatage and
+current regulators, rtc, charger controller and other sub-blocks. It is
+interfaced to the host controller using a i2c interface. Each sub-block is
+addressed by the host system using different i2c slave address. This document
+describes the bindings for 'pmic' sub-block of s5m8767.
+Required properties:
+- compatible: Should be "samsung,s5m8767-pmic".
+- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
+- s5m8767,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
+  units for buck2 when changing voltage using gpio dvs. Refer to [1] below
+  for additional information.
+- s5m8767,pmic-buck3-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
+  units for buck3 when changing voltage using gpio dvs. Refer to [1] below
+  for additional information.
+- s5m8767,pmic-buck4-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
+  units for buck4 when changing voltage using gpio dvs. Refer to [1] below
+  for additional information.
+- s5m8767,pmic-buck-ds-gpios: GPIO specifiers for three host gpio's used
+  for selecting GPIO DVS lines. It is one-to-one mapped to dvs gpio lines.
+[1] If none of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
+    property is specified, the 's5m8767,pmic-buck[2/3/4]-dvs-voltage'
+    property should specify atleast one voltage level (which would be a
+    safe operating voltage).
+    If either of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
+    property is specified, then all the eight voltage values for the
+    's5m8767,pmic-buck[2/3/4]-dvs-voltage' should be specified.
+Optional properties:
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+  the interrupts from s5m8767 are delivered to.
+- interrupts: Interrupt specifiers for two interrupt sources.
+  - First interrupt specifier is for 'irq1' interrupt.
+  - Second interrupt specifier is for 'alert' interrupt.
+- s5m8767,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
+- s5m8767,pmic-buck3-uses-gpio-dvs: 'buck3' can be controlled by gpio dvs.
+- s5m8767,pmic-buck4-uses-gpio-dvs: 'buck4' can be controlled by gpio dvs.
+Additional properties required if either of the optional properties are used:
+- s5m8767,pmic-buck234-default-dvs-idx: Default voltage setting selected from
+  the possible 8 options selectable by the dvs gpios. The value of this
+  property should be between 0 and 7. If not specified or if out of range, the
+  default value of this property is set to 0.
+- s5m8767,pmic-buck-dvs-gpios: GPIO specifiers for three host gpio's used
+  for dvs. The format of the gpio specifier depends in the gpio controller.
+Regulators: The regulators of s5m8767 that have to be instantiated should be
+included in a sub-node named 'regulators'. Regulator nodes included in this
+sub-node should be of the format as listed below.
+        regulator_name {
+                ldo1_reg: LDO1 {
+                        regulator-name = "VDD_ALIVE_1.0V";
+                        regulator-min-microvolt = <1100000>;
+                        regulator-max-microvolt = <1100000>;
+                        regulator-always-on;
+                        regulator-boot-on;
+                        op_mode = <1>; /* Normal Mode */
+                };
+        };
+The above regulator entries are defined in regulator bindings documentation
+except op_mode description.
+        - op_mode: describes the different operating modes of the LDO's with
+                power mode change in SOC. The different possible values are,
+                0 - always off mode
+                1 - on in normal mode
+                2 - low power mode
+                3 - suspend mode
+The following are the names of the regulators that the s5m8767 pmic block
+supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
+as per the datasheet of s5m8767.
+        - LDOn
+                  - valid values for n are 1 to 28
+                  - Example: LDO0, LD01, LDO28
+        - BUCKn
+                  - valid values for n are 1 to 9.
+                  - Example: BUCK1, BUCK2, BUCK9
+The bindings inside the regulator nodes use the standard regulator bindings
+which are documented elsewhere.
+Example:
+        s5m8767_pmic@66 {
+                compatible = "samsung,s5m8767-pmic";
+                reg = <0x66>;
+                s5m8767,pmic-buck2-uses-gpio-dvs;
+                s5m8767,pmic-buck3-uses-gpio-dvs;
+                s5m8767,pmic-buck4-uses-gpio-dvs;
+                s5m8767,pmic-buck-default-dvs-idx = <0>;
+                s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 1 0 0>, /* DVS1 */
+                                                 <&gpx0 1 1 0 0>, /* DVS2 */
+                                                 <&gpx0 2 1 0 0>; /* DVS3 */
+                s5m8767,pmic-buck-ds-gpios = <&gpx2 3 1 0 0>, /* SET1 */
+                                                <&gpx2 4 1 0 0>, /* SET2 */
+                                                <&gpx2 5 1 0 0>; /* SET3 */
+                s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>,
+                                                 <1250000>, <1200000>,
+                                                 <1150000>, <1100000>,
+                                                 <1000000>, <950000>;
+                s5m8767,pmic-buck3-dvs-voltage = <1100000>, <1100000>,
+                                                 <1100000>, <1100000>,
+                                                 <1000000>, <1000000>,
+                                                 <1000000>, <1000000>;
+                s5m8767,pmic-buck4-dvs-voltage = <1200000>, <1200000>,
+                                                 <1200000>, <1200000>,
+                                                 <1200000>, <1200000>,
+                                                 <1200000>, <1200000>;
+                regulators {
+                        ldo1_reg: LDO1 {
+                                regulator-name = "VDD_ABB_3.3V";
+                                regulator-min-microvolt = <3300000>;
+                                regulator-max-microvolt = <3300000>;
+                                op_mode = <1>; /* Normal Mode */
+                        };
+                        ldo2_reg: LDO2 {
+                                regulator-name = "VDD_ALIVE_1.1V";
+                                regulator-min-microvolt = <1100000>;
+                                regulator-max-microvolt = <1100000>;
+                                regulator-always-on;
+                        };
+                        buck1_reg: BUCK1 {
+                                regulator-name = "VDD_MIF_1.2V";
+                                regulator-min-microvolt = <950000>;
+                                regulator-max-microvolt = <1350000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/regulator/tps51632-regulator.txt b/Documentation/devicetree/bindings/regulator/tps51632-regulator.txt
new file mode 100644
index 000000000000..2f7e44a96414
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps51632-regulator.txt
@@ -0,0 +1,27 @@
+TPS51632 Voltage regulators
+Required properties:
+- compatible: Must be "ti,tps51632"
+- reg: I2C slave address
+Optional properties:
+- ti,enable-pwm-dvfs: Enable the DVFS voltage control through the PWM interface.
+- ti,dvfs-step-20mV: The 20mV step voltage when PWM DVFS enabled. Missing this
+        will set 10mV step voltage in PWM DVFS mode. In normal mode, the voltage
+        step is 10mV as per datasheet.
+Any property defined as part of the core regulator binding, defined in
+regulator.txt, can also be used.
+Example:
+        tps51632 {
+                compatible = "ti,tps51632";
+                reg =  <0x43>;
+                regulator-name = "tps51632-vout";
+                regulator-min-microvolt = <500000>;
+                regulator-max-microvolt = <1500000>;
+                regulator-boot-on;
+                ti,enable-pwm-dvfs;
+                ti,dvfs-step-20mV;
+        };
diff --git a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt
index c8ca6b8f6582..1b20c3dbcdb8 100644
--- a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt
@@ -17,9 +17,9 @@ Optional properties:
 - ti,vsel1-gpio: Gpio for controlling VSEL1 line.
  If this property is missing, then assume that there is no GPIO
  for vsel1 control.
- ti,vsel0-state-high: Inital state of vsel0 input is high.
+- ti,vsel0-state-high: Initial state of vsel0 input is high.
  If this property is missing, then assume the state as low (0).
- ti,vsel1-state-high: Inital state of vsel1 input is high.
+- ti,vsel1-state-high: Initial state of vsel1 input is high.
  If this property is missing, then assume the state as low (0).
 Any property defined as part of the core regulator binding, defined in
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt b/Documentation/devicetree/bindings/regulator/tps65090.txt
new file mode 100644
index 000000000000..313a60ba61d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -0,0 +1,122 @@
+TPS65090 regulators
+Required properties:
+- compatible: "ti,tps65090"
+- reg: I2C slave address
+- interrupts: the interrupt outputs of the controller
+- regulators: A node that houses a sub-node for each regulator within the
+  device. Each sub-node is identified using the node's name, with valid
+  values listed below. The content of each sub-node is defined by the
+  standard binding for regulators; see regulator.txt.
+  dcdc[1-3], fet[1-7] and ldo[1-2] respectively.
+- vsys[1-3]-supply: The input supply for DCDC[1-3] respectively.
+- infet[1-7]-supply: The input supply for FET[1-7] respectively.
+- vsys-l[1-2]-supply: The input supply for LDO[1-2] respectively.
+Optional properties:
+- ti,enable-ext-control: This is applicable for DCDC1, DCDC2 and DCDC3.
+  If DCDCs are externally controlled then this property should be there.
+- "dcdc-ext-control-gpios: This is applicable for DCDC1, DCDC2 and DCDC3.
+  If DCDCs are externally controlled and if it is from GPIO then GPIO
+  number should be provided. If it is externally controlled and no GPIO
+  entry then driver will just configure this rails as external control
+  and will not provide any enable/disable APIs.
+Each regulator is defined using the standard binding for regulators.
+Example:
+        tps65090@48 {
+                compatible = "ti,tps65090";
+                reg = <0x48>;
+                interrupts = <0 88 0x4>;
+                vsys1-supply = <&some_reg>;
+                vsys2-supply = <&some_reg>;
+                vsys3-supply = <&some_reg>;
+                infet1-supply = <&some_reg>;
+                infet2-supply = <&some_reg>;
+                infet3-supply = <&some_reg>;
+                infet4-supply = <&some_reg>;
+                infet5-supply = <&some_reg>;
+                infet6-supply = <&some_reg>;
+                infet7-supply = <&some_reg>;
+                vsys_l1-supply = <&some_reg>;
+                vsys_l2-supply = <&some_reg>;
+                regulators {
+                        dcdc1 {
+                                regulator-name = "dcdc1";
+                                regulator-boot-on;
+                                regulator-always-on;
+                                ti,enable-ext-control;
+                                dcdc-ext-control-gpios = <&gpio 10 0>;
+                        };
+                        dcdc2 {
+                                regulator-name = "dcdc2";
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                        dcdc3 {
+                                regulator-name = "dcdc3";
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                        fet1 {
+                                regulator-name = "fet1";
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                        fet2 {
+                                regulator-name = "fet2";
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                        fet3 {
+                                regulator-name = "fet3";
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                        fet4 {
+                                regulator-name = "fet4";
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                        fet5 {
+                                regulator-name = "fet5";
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                        fet6 {
+                                regulator-name = "fet6";
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                        fet7 {
+                                regulator-name = "fet7";
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                        ldo1 {
+                                regulator-name = "ldo1";
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                        ldo2 {
+                                regulator-name = "ldo2";
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
index 90ec45fd33ec..7ac7259fe9ea 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
@@ -7,7 +7,7 @@ Required properties:
 - reg: physical base address of the controller and length of memory mapped
  region.
 - interrupts: Two interrupt numbers to the cpu should be specified. First
-  interrupt number is the rtc alarm interupt and second interrupt number
+  interrupt number is the rtc alarm interrupt and second interrupt number
  is the rtc tick interrupt. The number of cells representing a interrupt
  depends on the parent interrupt controller.
diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
new file mode 100644
index 000000000000..392a4493eebd
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
@@ -0,0 +1,24 @@
+NVIDIA Tegra20/Tegra30 high speed (DMA based) UART controller driver.
+Required properties:
+- compatible : should be "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart".
+- reg: Should contain UART controller registers location and length.
+- interrupts: Should contain UART controller interrupts.
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+  request selector for this UART controller.
+Optional properties:
+- nvidia,enable-modem-interrupt: Enable modem interrupts. Should be enable
+                only if all 8 lines of UART controller are pinmuxed.
+Example:
+serial@70006000 {
+        compatible = "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart";
+        reg = <0x70006000 0x40>;
+        reg-shift = <2>;
+        interrupts = <0 36 0x04>;
+        nvidia,dma-request-selector = <&apbdma 8>;
+        nvidia,enable-modem-interrupt;
+        status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/sound/ak4642.txt b/Documentation/devicetree/bindings/sound/ak4642.txt
new file mode 100644
index 000000000000..623d4e70ae11
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ak4642.txt
@@ -0,0 +1,17 @@
+AK4642 I2C transmitter
+This device supports I2C mode only.
+Required properties:
+  - compatible : "asahi-kasei,ak4642" or "asahi-kasei,ak4643" or "asahi-kasei,ak4648"
+  - reg : The chip select number on the I2C bus
+Example:
+&i2c {
+        ak4648: ak4648@0x12 {
+                compatible = "asahi-kasei,ak4642";
+                reg = <0x12>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/sound/cs4271.txt b/Documentation/devicetree/bindings/sound/cs4271.txt
index a850fb9c88ea..e2cd1d7539e5 100644
--- a/Documentation/devicetree/bindings/sound/cs4271.txt
+++ b/Documentation/devicetree/bindings/sound/cs4271.txt
@@ -20,6 +20,18 @@ Optional properties:
                !RESET pin
 - cirrus,amuteb-eq-bmutec:     When given, the Codec's AMUTEB=BMUTEC flag
                                is enabled.
+ - cirrus,enable-soft-reset:
+        The CS4271 requires its LRCLK and MCLK to be stable before its RESET
+        line is de-asserted. That also means that clocks cannot be changed
+        without putting the chip back into hardware reset, which also requires
+        a complete re-initialization of all registers.
+        One (undocumented) workaround is to assert and de-assert the PDN bit
+        in the MODE2 register. This workaround can be enabled with this DT
+        property.
+        Note that this is not needed in case the clocks are stable
+        throughout the entire runtime of the codec.
 Examples:
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt
new file mode 100644
index 000000000000..be35d34e8b26
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt
@@ -0,0 +1,51 @@
+NVIDIA Tegra audio complex
+Required properties:
+- compatible : "nvidia,tegra-audio-wm9712"
+- nvidia,model : The user-visible name of this sound complex.
+- nvidia,audio-routing : A list of the connections between audio components.
+  Each entry is a pair of strings, the first being the connection's sink,
+  the second being the connection's source. Valid names for sources and
+  sinks are the WM9712's pins, and the jacks on the board:
+  WM9712 pins:
+  * MONOOUT
+  * HPOUTL
+  * HPOUTR
+  * LOUT2
+  * ROUT2
+  * OUT3
+  * LINEINL
+  * LINEINR
+  * PHONE
+  * PCBEEP
+  * MIC1
+  * MIC2
+  * Mic Bias
+  Board connectors:
+  * Headphone
+  * LineIn
+  * Mic
+- nvidia,ac97-controller : The phandle of the Tegra AC97 controller
+Example:
+sound {
+        compatible = "nvidia,tegra-audio-wm9712-colibri_t20",
+                         "nvidia,tegra-audio-wm9712";
+        nvidia,model = "Toradex Colibri T20";
+        nvidia,audio-routing =
+                "Headphone", "HPOUTL",
+                "Headphone", "HPOUTR",
+                "LineIn", "LINEINL",
+                "LineIn", "LINEINR",
+                "Mic", "MIC1";
+        nvidia,ac97-controller = <&ac97>;
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
new file mode 100644
index 000000000000..c1454979c1ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
@@ -0,0 +1,22 @@
+NVIDIA Tegra 20 AC97 controller
+Required properties:
+- compatible : "nvidia,tegra20-ac97"
+- reg : Should contain AC97 controller registers location and length
+- interrupts : Should contain AC97 interrupt
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+  request selector for the AC97 controller
+- nvidia,codec-reset-gpio : The Tegra GPIO controller's phandle and the number
+  of the GPIO used to reset the external AC97 codec
+- nvidia,codec-sync-gpio : The Tegra GPIO controller's phandle and the number
+  of the GPIO corresponding with the AC97 DAP _FS line
+Example:
+ac97@70002000 {
+        compatible = "nvidia,tegra20-ac97";
+        reg = <0x70002000 0x200>;
+        interrupts = <0 81 0x04>;
+        nvidia,dma-request-selector = <&apbdma 12>;
+        nvidia,codec-reset-gpio = <&gpio 170 0>;
+        nvidia,codec-sync-gpio = <&gpio 120 0>;
+};
diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
index 6fae51c7f766..1ab6bc8404d5 100644
--- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
+++ b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
@@ -6,6 +6,52 @@ Required properties:
 - ti,mcbsp: phandle for the McBSP node
 - ti,codec: phandle for the twl4030 audio node
+Optional properties:
+- ti,mcbsp-voice: phandle for the McBSP node connected to the voice port of twl
+- ti, jack-det-gpio: Jack detect GPIO
+- ti,audio-routing: List of connections between audio components.
+  Each entry is a pair of strings, the first being the connection's sink,
+  the second being the connection's source.
+  If the routing is not provided all possible connection will be available
+Available audio endpoints for the audio-routing table:
+Board connectors:
+ * Headset Stereophone
+ * Earpiece Spk
+ * Handsfree Spk
+ * Ext Spk
+ * Main Mic
+ * Sub Mic
+ * Headset Mic
+ * Carkit Mic
+ * Digital0 Mic
+ * Digital1 Mic
+ * Line In
+twl4030 pins:
+ * HSOL
+ * HSOR
+ * EARPIECE
+ * HFL
+ * HFR
+ * PREDRIVEL
+ * PREDRIVER
+ * CARKITL
+ * CARKITR
+ * MAINMIC
+ * SUBMIC
+ * HSMIC
+ * DIGIMIC0
+ * DIGIMIC1
+ * CARKITMIC
+ * AUXL
+ * AUXR
+ * Headset Mic Bias
+ * Mic Bias 1 /* Used for Main Mic or Digimic0 */
+ * Mic Bias 2 /* Used for Sub Mic or Digimic1 */
 Example:
 sound {
diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.txt b/Documentation/devicetree/bindings/sound/renesas,fsi.txt
new file mode 100644
index 000000000000..c5be003f413e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/renesas,fsi.txt
@@ -0,0 +1,26 @@
+Renesas FSI
+Required properties:
+- compatible                    : "renesas,sh_fsi2" or "renesas,sh_fsi"
+- reg                           : Should contain the register physical address and length
+- interrupts                    : Should contain FSI interrupt
+- fsia,spdif-connection         : FSI is connected by S/PDFI
+- fsia,stream-mode-support      : FSI supports 16bit stream mode.
+- fsia,use-internal-clock       : FSI uses internal clock when master mode.
+- fsib,spdif-connection         : same as fsia
+- fsib,stream-mode-support      : same as fsia
+- fsib,use-internal-clock       : same as fsia
+Example:
+sh_fsi2: sh_fsi2@0xec230000 {
+        compatible = "renesas,sh_fsi2";
+        reg = <0xec230000 0x400>;
+        interrupts = <0 146 0x4>;
+        fsia,spdif-connection;
+        fsia,stream-mode-support;
+        fsia,use-internal-clock;
+};
diff --git a/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt b/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt
new file mode 100644
index 000000000000..4686646fb122
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt
@@ -0,0 +1,14 @@
+Samsung SMDK audio complex
+Required properties:
+- compatible : "samsung,smdk-wm8994"
+- samsung,i2s-controller: The phandle of the Samsung I2S0 controller
+- samsung,audio-codec: The phandle of the WM8994 audio codec
+Example:
+sound {
+                compatible = "samsung,smdk-wm8994";
+                samsung,i2s-controller = <&i2s0>;
+                samsung,audio-codec = <&wm8994>;
+};
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
new file mode 100644
index 000000000000..3070046da2e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
@@ -0,0 +1,63 @@
+* Samsung I2S controller
+Required SoC Specific Properties:
+- compatible : "samsung,i2s-v5"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- dmas: list of DMA controller phandle and DMA request line ordered pairs.
+- dma-names: identifier string for each DMA request line in the dmas property.
+  These strings correspond 1:1 with the ordered pairs in dmas.
+Optional SoC Specific Properties:
+- samsung,supports-6ch: If the I2S Primary sound source has 5.1 Channel
+  support, this flag is enabled.
+- samsung,supports-rstclr: This flag should be set if I2S software reset bit
+  control is required. When this flag is set I2S software reset bit will be
+  enabled or disabled based on need.
+- samsung,supports-secdai:If I2S block has a secondary FIFO and internal DMA,
+  then this flag is enabled.
+- samsung,idma-addr: Internal DMA register base address of the audio
+  sub system(used in secondary sound source).
+Required Board Specific Properties:
+- gpios: The gpio specifier for data out,data in, LRCLK, CDCLK and SCLK
+  interface lines. The format of the gpio specifier depends on the gpio
+  controller.
+  The syntax of samsung gpio specifier is
+        <[phandle of the gpio controller node]
+         [pin number within the gpio controller]
+         [mux function]
+         [flags and pull up/down]
+         [drive strength]>
+Example:
+- SoC Specific Portion:
+i2s@03830000 {
+        compatible = "samsung,i2s-v5";
+        reg = <0x03830000 0x100>;
+        dmas = <&pdma0 10
+                &pdma0 9
+                &pdma0 8>;
+        dma-names = "tx", "rx", "tx-sec";
+        samsung,supports-6ch;
+        samsung,supports-rstclr;
+        samsung,supports-secdai;
+        samsung,idma-addr = <0x03000000>;
+};
+- Board Specific Portion:
+i2s@03830000 {
+        gpios = <&gpz 0 2 0 0>, /* I2S_0_SCLK */
+                <&gpz 1 2 0 0>, /* I2S_0_CDCLK */
+                <&gpz 2 2 0 0>, /* I2S_0_LRCK */
+                <&gpz 3 2 0 0>, /* I2S_0_SDI */
+                <&gpz 4 2 0 0>, /* I2S_0_SDO[1] */
+                <&gpz 5 2 0 0>, /* I2S_0_SDO[2] */
+                <&gpz 6 2 0 0>; /* I2S_0_SDO[3] */
+};
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index e7b98f41fa5f..f47c3f589fd0 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -11,6 +11,12 @@ Optional properties:
 - gpio-reset - gpio pin number used for codec reset
 - ai3x-gpio-func - <array of 2 int> - AIC3X_GPIO1 & AIC3X_GPIO2 Functionality
+- ai3x-micbias-vg - MicBias Voltage required.
+        1 - MICBIAS output is powered to 2.0V,
+        2 - MICBIAS output is powered to 2.5V,
+        3 - MICBIAS output is connected to AVDD,
+        If this node is not mentioned or if the value is incorrect, then MicBias
+        is powered down.
 Example:
diff --git a/Documentation/devicetree/bindings/sound/wm8962.txt b/Documentation/devicetree/bindings/sound/wm8962.txt
new file mode 100644
index 000000000000..dceb3b1c2bb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wm8962.txt
@@ -0,0 +1,16 @@
+WM8962 audio CODEC
+This device supports I2C only.
+Required properties:
+  - compatible : "wlf,wm8962"
+  - reg : the I2C address of the device.
+Example:
+codec: wm8962@1a {
+        compatible = "wlf,wm8962";
+        reg = <0x1a>;
+};
diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt
new file mode 100644
index 000000000000..e6222106ca36
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -0,0 +1,12 @@
+Renesas MSIOF spi controller
+Required properties:
+- compatible :  "renesas,sh-msiof" for SuperH or
+                "renesas,sh-mobile-msiof" for SH Mobile series
+- reg : Offset and length of the register set for the device
+- interrupts : interrupt line used by MSIOF
+Optional properties:
+- num-cs                : total number of chip-selects
+- renesas,tx-fifo-size  : Overrides the default tx fifo size given in words
+- renesas,rx-fifo-size  : Overrides the default rx fifo size given in words
diff --git a/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt b/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt
index 801d58cb6d4d..46882058b59b 100644
--- a/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt
+++ b/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt
@@ -5,6 +5,12 @@ Required properties:
 - reg: Address and length of the register set for the device
 - interrupts: Should contain the LRADC interrupts
+Optional properties:
+- fsl,lradc-touchscreen-wires: Number of wires used to connect the touchscreen
+                               to LRADC. Valid value is either 4 or 5. If this
+                               property is not present, then the touchscreen is
+                               disabled.
 Examples:
        lradc@80050000 {
diff --git a/Documentation/devicetree/bindings/tty/serial/arc-uart.txt b/Documentation/devicetree/bindings/tty/serial/arc-uart.txt
new file mode 100644
index 000000000000..5cae2eb686f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/arc-uart.txt
@@ -0,0 +1,26 @@
+* Synopsys ARC UART : Non standard UART used in some of the ARC FPGA boards
+Required properties:
+- compatible            : "snps,arc-uart"
+- reg                   : offset and length of the register set for the device.
+- interrupts            : device interrupt
+- clock-frequency       : the input clock frequency for the UART
+- current-speed         : baud rate for UART
+e.g.
+arcuart0: serial@c0fc1000 {
+        compatible = "snps,arc-uart";
+        reg = <0xc0fc1000 0x100>;
+        interrupts = <5>;
+        clock-frequency = <80000000>;
+        current-speed = <115200>;
+        status = "okay";
+};
+Note: Each port should have an alias correctly numbered in "aliases" node.
+e.g.
+aliases {
+        serial0 = &arcuart0;
+};
diff --git a/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt b/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt
index 6588b6950a7f..8e080b893b49 100644
--- a/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt
@@ -5,10 +5,16 @@ Required properties:
 - reg : Address and length of the register set
 - interrupts : Should contain uart interrupt
+Optional properties:
+- location : Decides the location of the USART I/O pins.
+  Allowed range : [0 .. 5]
+  Default: 0
 Example:
 uart@0x4000c400 {
        compatible = "efm32,uart";
        reg = <0x4000c400 0x400>;
        interrupts = <15>;
+        location = <0>;
 };
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
new file mode 100644
index 000000000000..7a95c651ceb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -0,0 +1,22 @@
+synopsys DWC3 CORE
+DWC3- USB3 CONTROLLER
+Required properties:
+ - compatible: must be "synopsys,dwc3"
+ - reg : Address and length of the register set for the device
+ - interrupts: Interrupts used by the dwc3 controller.
+ - usb-phy : array of phandle for the PHY device
+Optional properties:
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+This is usually a subnode to DWC3 glue to which it is connected.
+dwc3@4a030000 {
+        compatible = "synopsys,dwc3";
+        reg = <0x4a030000 0xcfff>;
+        interrupts = <0 92 4>
+        usb-phy = <&usb2_phy>, <&usb3,phy>;
+        tx-fifo-resize;
+};
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
index e9b005dc7625..34c952883276 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
@@ -11,6 +11,7 @@ Required properties :
 - phy_type : Should be one of "ulpi" or "utmi".
 - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
   activated for the bus to be powered.
+ - nvidia,phy : phandle of the PHY instance, the controller is connected to.
 Required properties for phy_type == ulpi:
  - nvidia,phy-reset-gpio : The GPIO used to reset the PHY.
@@ -27,3 +28,5 @@ Optional properties:
    registers are accessed through the APB_MISC base address instead of
    the USB controller. Since this is a legacy issue it probably does not
    warrant a compatible string of its own.
+  - nvidia,needs-double-reset : boolean is to be set for some of the Tegra2
+    USB ports, which need reset twice due to hardware issues.
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
new file mode 100644
index 000000000000..6bdaba2f0aa1
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
@@ -0,0 +1,17 @@
+Tegra SOC USB PHY
+The device node for Tegra SOC USB PHY:
+Required properties :
+ - compatible : Should be "nvidia,tegra20-usb-phy".
+ - reg : Address and length of the register set for the USB PHY interface.
+ - phy_type : Should be one of "ulpi" or "utmi".
+Required properties for phy_type == ulpi:
+  - nvidia,phy-reset-gpio : The GPIO used to reset the PHY.
+Optional properties:
+  - nvidia,has-legacy-mode : boolean indicates whether this controller can
+    operate in legacy mode (as APX 2500 / 2600). In legacy mode some
+    registers are accessed through the APB_MISC base address instead of
+    the USB controller.
+\ No newline at end of file
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043ecda52..1ef0ce71f8fa 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,8 +1,11 @@
-OMAP GLUE
+OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
 OMAP MUSB GLUE
 - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
 - ti,hwmods : must be "usb_otg_hs"
+ - ti,has-mailbox : to specify that omap uses an external mailbox
+   (in control module) to communicate with the musb core during device connect
+   and disconnect.
 - multipoint : Should be "1" indicating the musb controller supports
   multipoint. This is a MUSB configuration-specific setting.
 - num_eps : Specifies the number of endpoints. This is also a
@@ -16,13 +19,19 @@ OMAP MUSB GLUE
 - power : Should be "50". This signifies the controller can supply upto
   100mA when operating in host mode.
+Optional properties:
+ - ctrl-module : phandle of the control module this glue uses to write to
+   mailbox
 SOC specific device node entry
 usb_otg_hs: usb_otg_hs@4a0ab000 {
        compatible = "ti,omap4-musb";
        ti,hwmods = "usb_otg_hs";
+        ti,has-mailbox;
        multipoint = <1>;
        num_eps = <16>;
        ram_bits = <12>;
+        ctrl-module = <&omap_control_usb>;
 };
 Board specific device node entry
@@ -31,3 +40,26 @@ Board specific device node entry
        mode = <3>;
        power = <50>;
 };
+OMAP CONTROL USB
+Required properties:
+ - compatible: Should be "ti,omap-control-usb"
+ - reg : Address and length of the register set for the device. It contains
+   the address of "control_dev_conf" and "otghs_control" or "phy_power_usb"
+   depending upon omap4 or omap5.
+ - reg-names: The names of the register addresses corresponding to the registers
+   filled in "reg".
+ - ti,type: This is used to differentiate whether the control module has
+   usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
+   notify events to the musb core and omap5 has usb3 phy power register to
+   power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3
+   phy power.
+omap_control_usb: omap-control-usb@4a002300 {
+        compatible = "ti,omap-control-usb";
+        reg = <0x4a002300 0x4>,
+              <0x4a00233c 0x4>;
+        reg-names = "control_dev_conf", "otghs_control";
+        ti,type = <1>;
+};
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
new file mode 100644
index 000000000000..033194934f64
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -0,0 +1,55 @@
+* Samsung's usb phy transceiver
+The Samsung's phy transceiver is used for controlling usb phy for
+s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers
+across Samsung SOCs.
+TODO: Adding the PHY binding with controller(s) according to the under
+developement generic PHY driver.
+Required properties:
+Exynos4210:
+- compatible : should be "samsung,exynos4210-usbphy"
+- reg : base physical address of the phy registers and length of memory mapped
+        region.
+Exynos5250:
+- compatible : should be "samsung,exynos5250-usbphy"
+- reg : base physical address of the phy registers and length of memory mapped
+        region.
+Optional properties:
+- #address-cells: should be '1' when usbphy node has a child node with 'reg'
+                  property.
+- #size-cells: should be '1' when usbphy node has a child node with 'reg'
+               property.
+- ranges: allows valid translation between child's address space and parent's
+          address space.
+- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
+  interface for usb-phy. It should provide the following information required by
+  usb-phy controller to control phy.
+  - reg : base physical address of PHY_CONTROL registers.
+          The size of this register is the total sum of size of all PHY_CONTROL
+          registers that the SoC has. For example, the size will be
+          '0x4' in case we have only one PHY_CONTROL register (e.g.
+          OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210)
+          and, '0x8' in case we have two PHY_CONTROL registers (e.g.
+          USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x).
+          and so on.
+Example:
+ - Exynos4210
+        usbphy@125B0000 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                compatible = "samsung,exynos4210-usbphy";
+                reg = <0x125B0000 0x100>;
+                ranges;
+                usbphy-sys {
+                        /* USB device and host PHY_CONTROL registers */
+                        reg = <0x10020704 0x8>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 80d4148cb661..61496f5cb095 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -4,14 +4,39 @@ OMAP USB2 PHY
 Required properties:
 - compatible: Should be "ti,omap-usb2"
- - reg : Address and length of the register set for the device. Also
+ - reg : Address and length of the register set for the device.
-add the address of control module dev conf register until a driver for
-control module is added
+Optional properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+   the PHY.
 This is usually a subnode of ocp2scp to which it is connected.
 usb2phy@4a0ad080 {
        compatible = "ti,omap-usb2";
-        reg = <0x4a0ad080 0x58>,
+        reg = <0x4a0ad080 0x58>;
-              <0x4a002300 0x4>;
+        ctrl-module = <&omap_control_usb>;
+};
+OMAP USB3 PHY
+Required properties:
+ - compatible: Should be "ti,omap-usb3"
+ - reg : Address and length of the register set for the device.
+ - reg-names: The names of the register addresses corresponding to the registers
+   filled in "reg".
+Optional properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+   the PHY.
+This is usually a subnode of ocp2scp to which it is connected.
+usb3phy@4a084400 {
+        compatible = "ti,omap-usb3";
+        reg = <0x4a084400 0x80>,
+              <0x4a084800 0x64>,
+              <0x4a084c00 0x40>;
+        reg-names = "phy_rx", "phy_tx", "pll_ctrl";
+        ctrl-module = <&omap_control_usb>;
 };
diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt
new file mode 100644
index 000000000000..6813a715fc7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb3503.txt
@@ -0,0 +1,20 @@
+SMSC USB3503 High-Speed Hub Controller
+Required properties:
+- compatible: Should be "smsc,usb3503".
+- reg: Specifies the i2c slave address, it should be 0x08.
+- connect-gpios: Should specify GPIO for connect.
+- intn-gpios: Should specify GPIO for interrupt.
+- reset-gpios: Should specify GPIO for reset.
+- initial-mode: Should specify initial mode.
+                (1 for HUB mode, 2 for STANDBY mode)
+Examples:
+        usb3503@08 {
+                compatible = "smsc,usb3503";
+                reg = <0x08>;
+                connect-gpios = <&gpx3 0 1>;
+                intn-gpios = <&gpx3 4 1>;
+                reset-gpios = <&gpx3 5 1>;
+                initial-mode = <1>;
+        };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 902b1b1f568e..19e1ef73ab0d 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -14,6 +14,7 @@ bosch	Bosch Sensortec GmbH
 brcm    Broadcom Corporation
 cavium  Cavium, Inc.
 chrp    Common Hardware Reference Platform
+cirrus  Cirrus Logic, Inc.
 cortina Cortina Systems, Inc.
 dallas  Maxim Integrated Products (formerly Dallas Semiconductor)
 denx    Denx Software Engineering
@@ -42,6 +43,7 @@ powervr	PowerVR (deprecated, use img)
 qcom    Qualcomm, Inc.
 ramtron Ramtron International
 realtek Realtek Semiconductor Corp.
+renesas Renesas Electronics Corporation
 samsung Samsung Semiconductor
 sbs     Smart Battery System
 schindler       Schindler
@@ -50,8 +52,10 @@ simtek
 sirf    SiRF Technology, Inc.
 snps    Synopsys, Inc.
 st      STMicroelectronics
+ste     ST-Ericsson
 stericsson      ST-Ericsson
 ti      Texas Instruments
+toshiba Toshiba Corporation
 via     VIA Technologies, Inc.
 wlf     Wolfson Microelectronics
 wm      Wondermedia Technologies, Inc.
diff --git a/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt b/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
new file mode 100644
index 000000000000..b4cffdaa4137
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
@@ -0,0 +1,10 @@
+88pm860x-backlight bindings
+Optional properties:
+  - maxim,max8925-dual-string: whether support dual string
+Example:
+        backlights {
+                maxim,max8925-dual-string = <0>;
+        };
diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt
new file mode 100644
index 000000000000..150038552bc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timing.txt
@@ -0,0 +1,109 @@
+display-timing bindings
+=======================
+display-timings node
+--------------------
+required properties:
+ - none
+optional properties:
+ - native-mode: The native mode for the display, in case multiple modes are
+                provided. When omitted, assume the first node is the native.
+timing subnode
+--------------
+required properties:
+ - hactive, vactive: display resolution
+ - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
+   in pixels
+   vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
+   lines
+ - clock-frequency: display clock in Hz
+optional properties:
+ - hsync-active: hsync pulse is active low/high/ignored
+ - vsync-active: vsync pulse is active low/high/ignored
+ - de-active: data-enable pulse is active low/high/ignored
+ - pixelclk-active: with
+                        - active high = drive pixel data on rising edge/
+                                        sample data on falling edge
+                        - active low  = drive pixel data on falling edge/
+                                        sample data on rising edge
+                        - ignored     = ignored
+ - interlaced (bool): boolean to enable interlaced mode
+ - doublescan (bool): boolean to enable doublescan mode
+All the optional properties that are not bool follow the following logic:
+    <1>: high active
+    <0>: low active
+    omitted: not used on hardware
+There are different ways of describing the capabilities of a display. The
+devicetree representation corresponds to the one commonly found in datasheets
+for displays. If a display supports multiple signal timings, the native-mode
+can be specified.
+The parameters are defined as:
+  +----------+-------------------------------------+----------+-------+
+  |          |        ↑                            |          |       |
+  |          |        |vback_porch                 |          |       |
+  |          |        ↓                            |          |       |
+  +----------#######################################----------+-------+
+  |          #        ↑                            #          |       |
+  |          #        |                            #          |       |
+  |  hback   #        |                            #  hfront  | hsync |
+  |   porch  #        |       hactive              #  porch   |  len  |
+  |<-------->#<-------+--------------------------->#<-------->|<----->|
+  |          #        |                            #          |       |
+  |          #        |vactive                     #          |       |
+  |          #        |                            #          |       |
+  |          #        ↓                            #          |       |
+  +----------#######################################----------+-------+
+  |          |        ↑                            |          |       |
+  |          |        |vfront_porch                |          |       |
+  |          |        ↓                            |          |       |
+  +----------+-------------------------------------+----------+-------+
+  |          |        ↑                            |          |       |
+  |          |        |vsync_len                   |          |       |
+  |          |        ↓                            |          |       |
+  +----------+-------------------------------------+----------+-------+
+Example:
+        display-timings {
+                native-mode = <&timing0>;
+                timing0: 1080p24 {
+                        /* 1920x1080p24 */
+                        clock-frequency = <52000000>;
+                        hactive = <1920>;
+                        vactive = <1080>;
+                        hfront-porch = <25>;
+                        hback-porch = <25>;
+                        hsync-len = <25>;
+                        vback-porch = <2>;
+                        vfront-porch = <2>;
+                        vsync-len = <2>;
+                        hsync-active = <1>;
+                };
+        };
+Every required property also supports the use of ranges, so the commonly used
+datasheet description with minimum, typical and maximum values can be used.
+Example:
+        timing1: timing {
+                /* 1920x1080p24 */
+                clock-frequency = <148500000>;
+                hactive = <1920>;
+                vactive = <1080>;
+                hsync-len = <0 44 60>;
+                hfront-porch = <80 88 95>;
+                hback-porch = <100 148 160>;
+                vfront-porch = <0 4 6>;
+                vback-porch = <0 36 50>;
+                vsync-len = <0 5 6>;
+        };
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
index 79ead8263ae4..ce0d8e78ed8f 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
@@ -2,7 +2,7 @@
 The Samsung's Watchdog controller is used for resuming system operation
 after a preset amount of time during which the WDT reset event has not
-occured.
+occurred.
 Required properties:
 - compatible : should be "samsung,s3c2410-wdt"
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt
index d4d66757354e..b2fb2f5e1922 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@@ -1228,7 +1228,7 @@ hierarchy and routing of interrupts in the hardware.
 The interrupt tree model is fully described in the
 document "Open Firmware Recommended Practice: Interrupt
 Mapping Version 0.9".  The document is available at:
-<http://playground.sun.com/1275/practice>.
+<http://www.openfirmware.org/ofwg/practice/>
 1) interrupts property
 ----------------------
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 43cff70465ab..b4671459857f 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -266,7 +266,8 @@ IOMAP
  devm_ioremap()
  devm_ioremap_nocache()
  devm_iounmap()
-  devm_request_and_ioremap() : checks resource, requests region, ioremaps
+  devm_ioremap_resource() : checks resource, requests memory region, ioremaps
+  devm_request_and_ioremap() : obsoleted by devm_ioremap_resource()
  pcim_iomap()
  pcim_iounmap()
  pcim_iomap_table()    : array of mapped addresses indexed by BAR
@@ -288,3 +289,7 @@ PINCTRL
 PWM
  devm_pwm_get()
  devm_pwm_put()
+PHY
+  devm_usb_get_phy()
+  devm_usb_put_phy()
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index 32bc56b13b1c..5d5ee4c13fa6 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -23,7 +23,7 @@ use IO::Handle;
 @components = ( "sp8870", "sp887x", "tda10045", "tda10046",
                "tda10046lifeview", "av7110", "dec2000t", "dec2540t",
-                "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
+                "dec3000s", "vp7041", "vp7049", "dibusb", "nxt2002", "nxt2004",
                "or51211", "or51132_qam", "or51132_vsb", "bluebird",
                "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
                "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
@@ -289,6 +289,19 @@ sub vp7041 {
    $outfile;
 }
+sub vp7049 {
+    my $fwfile = "dvb-usb-vp7049-0.95.fw";
+    my $url = "http://ao2.it/sites/default/files/blog/2012/11/06/linux-support-digicom-digitune-s-vp7049-udtt7049/$fwfile";
+    my $hash = "5609fd295168aea88b25ff43a6f79c36";
+    checkstandard();
+    wgetfile($fwfile, $url);
+    verify($fwfile, $hash);
+    $fwfile;
+}
 sub dibusb {
        my $url = "http://www.linuxtv.org/downloads/firmware/dvb-usb-dibusb-5.0.0.11.fw";
        my $outfile = "dvb-dibusb-5.0.0.11.fw";
@@ -677,7 +690,7 @@ sub drxk_terratec_h5 {
 }
 sub drxk_terratec_htc_stick {
-    my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/";
+    my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/History/";
    my $zipfile = "Cinergy_HTC_Stick_Drv_5.09.1202.00_XP_Vista_7.exe";
    my $hash = "6722a2442a05423b781721fbc069ed5e";
    my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);
diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt
index 6e1684981da2..72322c6d7352 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -6,8 +6,16 @@ This document describes how to use the dynamic debug (dyndbg) feature.
 Dynamic debug is designed to allow you to dynamically enable/disable
 kernel code to obtain additional kernel information.  Currently, if
-CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can
+CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() and
-be dynamically enabled per-callsite.
+print_hex_dump_debug()/print_hex_dump_bytes() calls can be dynamically
+enabled per-callsite.
+If CONFIG_DYNAMIC_DEBUG is not set, print_hex_dump_debug() is just
+shortcut for print_hex_dump(KERN_DEBUG).
+For print_hex_dump_debug()/print_hex_dump_bytes(), format string is
+its 'prefix_str' argument, if it is constant string; or "hexdump"
+in case 'prefix_str' is build dynamically.
 Dynamic debug has even more useful features:
@@ -202,6 +210,9 @@ The flags are:
  t    Include thread ID in messages not generated from interrupt context
  _    No flags are set. (Or'd with others on input)
+For print_hex_dump_debug() and print_hex_dump_bytes(), only 'p' flag
+have meaning, other flags ignored.
 For display, the flags are preceded by '='
 (mnemonic: what the flags are currently equal to).
diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt
index 8fbd8b46ee34..dcf338e62b71 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -175,9 +175,9 @@ consists of multiple segments as described below.
                                            align with the zone size <-|
                 |-> align with the segment size
     _________________________________________________________________________
-    |            |            |    Node     |   Segment   |   Segment  |      |
+    |            |            |   Segment   |    Node     |   Segment  |      |
-    | Superblock | Checkpoint |   Address   |    Info.    |   Summary  | Main |
+    | Superblock | Checkpoint |    Info.    |   Address   |   Summary  | Main |
-    |    (SB)    |   (CP)     | Table (NAT) | Table (SIT) | Area (SSA) |      |
+    |    (SB)    |   (CP)     | Table (SIT) | Table (NAT) | Area (SSA) |      |
    |____________|_____2______|______N______|______N______|______N_____|__N___|
                                                                       .      .
                                                             .                .
@@ -200,14 +200,14 @@ consists of multiple segments as described below.
 : It contains file system information, bitmaps for valid NAT/SIT sets, orphan
   inode lists, and summary entries of current active segments.
- Node Address Table (NAT)
- : It is composed of a block address table for all the node blocks stored in
-   Main area.
 - Segment Information Table (SIT)
 : It contains segment information such as valid block count and bitmap for the
   validity of all the blocks.
+- Node Address Table (NAT)
+ : It is composed of a block address table for all the node blocks stored in
+   Main area.
 - Segment Summary Area (SSA)
 : It contains summary entries which contains the owner information of all the
   data and node blocks stored in Main area.
@@ -236,13 +236,13 @@ For file system consistency, each CP points to which NAT and SIT copies are
 valid, as shown as below.
  +--------+----------+---------+
-  |   CP   |    NAT   |   SIT   |
+  |   CP   |    SIT   |   NAT   |
  +--------+----------+---------+
  .         .          .          .
  .            .              .              .
  .               .                 .                 .
  +-------+-------+--------+--------+--------+--------+
-  | CP #0 | CP #1 | NAT #0 | NAT #1 | SIT #0 | SIT #1 |
+  | CP #0 | CP #1 | SIT #0 | SIT #1 | NAT #0 | NAT #1 |
  +-------+-------+--------+--------+--------+--------+
     |             ^                          ^
     |             |                          |
diff --git a/Documentation/hid/hid-sensor.txt b/Documentation/hid/hid-sensor.txt
index 948b0989c433..948b0989c433 100755..100644
--- a/Documentation/hid/hid-sensor.txt
+++ b/Documentation/hid/hid-sensor.txt
diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp
index 3374c085678d..fec5a9bf755f 100644
--- a/Documentation/hwmon/coretemp
+++ b/Documentation/hwmon/coretemp
@@ -66,6 +66,7 @@ Process		Processor					TjMax(C)
                i5 3470T                                        91
 32nm            Core i3/i5/i7 Processors
+                i7 2600                                         98
                i7 660UM/640/620, 640LM/620, 620M, 610E         105
                i5 540UM/520/430, 540M/520/450/430              105
                i3 330E, 370M/350/330                           90 rPGA, 105 BGA
@@ -79,7 +80,10 @@ Process		Processor					TjMax(C)
                P4505/P4500                                     90
 32nm            Atom Processors
+                S1260/1220                                      95
+                S1240                                           102
                Z2460                                           90
+                Z2760                                           90
                D2700/2550/2500                                 100
                N2850/2800/2650/2600                            100
@@ -98,6 +102,7 @@ Process		Processor					TjMax(C)
 45nm            Atom Processors
                D525/510/425/410                                100
+                K525/510/425/410                                100
                Z670/650                                        90
                Z560/550/540/530P/530/520PT/520/515/510PT/510P  90
                Z510/500                                        90
@@ -107,7 +112,11 @@ Process		Processor					TjMax(C)
                330/230                                         125
                E680/660/640/620                                90
                E680T/660T/640T/620T                            110
+                E665C/645C                                      90
+                E665CT/645CT                                    110
                CE4170/4150/4110                                110
+                CE4200 series                                   unknown
+                CE5300 series                                   unknown
 45nm            Core2 Processors
                Solo ULV SU3500/3300                            100
diff --git a/Documentation/hwmon/ina209 b/Documentation/hwmon/ina209
new file mode 100644
index 000000000000..672501de4509
--- /dev/null
+++ b/Documentation/hwmon/ina209
@@ -0,0 +1,93 @@
+Kernel driver ina209
+=====================
+Supported chips:
+  * Burr-Brown / Texas Instruments INA209
+    Prefix: 'ina209'
+    Addresses scanned: -
+    Datasheet:
+        http://www.ti.com/lit/gpn/ina209
+Author: Paul Hays <Paul.Hays@cattail.ca>
+Author: Ira W. Snyder <iws@ovro.caltech.edu>
+Author: Guenter Roeck <linux@roeck-us.net>
+Description
+-----------
+The TI / Burr-Brown INA209 monitors voltage, current, and power on the high side
+of a D.C. power supply. It can perform measurements and calculations in the
+background to supply readings at any time. It includes a programmable
+calibration multiplier to scale the displayed current and power values.
+Sysfs entries
+-------------
+The INA209 chip is highly configurable both via hardwiring and via
+the I2C bus. See the datasheet for details.
+This tries to expose most monitoring features of the hardware via
+sysfs. It does not support every feature of this chip.
+in0_input               shunt voltage (mV)
+in0_input_highest       shunt voltage historical maximum reading (mV)
+in0_input_lowest        shunt voltage historical minimum reading (mV)
+in0_reset_history       reset shunt voltage history
+in0_max                 shunt voltage max alarm limit (mV)
+in0_min                 shunt voltage min alarm limit (mV)
+in0_crit_max            shunt voltage crit max alarm limit (mV)
+in0_crit_min            shunt voltage crit min alarm limit (mV)
+in0_max_alarm           shunt voltage max alarm limit exceeded
+in0_min_alarm           shunt voltage min alarm limit exceeded
+in0_crit_max_alarm      shunt voltage crit max alarm limit exceeded
+in0_crit_min_alarm      shunt voltage crit min alarm limit exceeded
+in1_input               bus voltage (mV)
+in1_input_highest       bus voltage historical maximum reading (mV)
+in1_input_lowest        bus voltage historical minimum reading (mV)
+in1_reset_history       reset bus voltage history
+in1_max                 bus voltage max alarm limit (mV)
+in1_min                 bus voltage min alarm limit (mV)
+in1_crit_max            bus voltage crit max alarm limit (mV)
+in1_crit_min            bus voltage crit min alarm limit (mV)
+in1_max_alarm           bus voltage max alarm limit exceeded
+in1_min_alarm           bus voltage min alarm limit exceeded
+in1_crit_max_alarm      bus voltage crit max alarm limit exceeded
+in1_crit_min_alarm      bus voltage crit min alarm limit exceeded
+power1_input            power measurement (uW)
+power1_input_highest    power historical maximum reading (uW)
+power1_reset_history    reset power history
+power1_max              power max alarm limit (uW)
+power1_crit             power crit alarm limit (uW)
+power1_max_alarm        power max alarm limit exceeded
+power1_crit_alarm       power crit alarm limit exceeded
+curr1_input             current measurement (mA)
+update_interval         data conversion time; affects number of samples used
+                        to average results for shunt and bus voltages.
+General Remarks
+---------------
+The power and current registers in this chip require that the calibration
+register is programmed correctly before they are used. Normally this is expected
+to be done in the BIOS. In the absence of BIOS programming, the shunt resistor
+voltage can be provided using platform data. The driver uses platform data from
+the ina2xx driver for this purpose. If calibration register data is not provided
+via platform data, the driver checks if the calibration register has been
+programmed (ie has a value not equal to zero). If so, this value is retained.
+Otherwise, a default value reflecting a shunt resistor value of 10 mOhm is
+programmed into the calibration register.
+Output Pins
+-----------
+Output pin programming is a board feature which depends on the BIOS. It is
+outside the scope of a hardware monitoring driver to enable or disable output
+pins.
diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87
index 8386aadc0a82..c263740f0cba 100644
--- a/Documentation/hwmon/it87
+++ b/Documentation/hwmon/it87
@@ -30,6 +30,14 @@ Supported chips:
    Prefix: 'it8728'
    Addresses scanned: from Super I/O config space (8 I/O ports)
    Datasheet: Not publicly available
+  * IT8771E
+    Prefix: 'it8771'
+    Addresses scanned: from Super I/O config space (8 I/O ports)
+    Datasheet: Not publicly available
+  * IT8772E
+    Prefix: 'it8772'
+    Addresses scanned: from Super I/O config space (8 I/O ports)
+    Datasheet: Not publicly available
  * IT8782F
    Prefix: 'it8782'
    Addresses scanned: from Super I/O config space (8 I/O ports)
@@ -83,8 +91,8 @@ Description
 -----------
 This driver implements support for the IT8705F, IT8712F, IT8716F,
-IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8781F, IT8782F,
+IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E, IT8772E,
-IT8783E/F, and SiS950 chips.
+IT8782F, IT8783E/F, and SiS950 chips.
 These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
 joysticks and other miscellaneous stuff. For hardware monitoring, they
@@ -118,8 +126,8 @@ The IT8726F is just bit enhanced IT8716F with additional hardware
 for AMD power sequencing. Therefore the chip will appear as IT8716F
 to userspace applications.
-The IT8728F is considered compatible with the IT8721F, until a datasheet
+The IT8728F, IT8771E, and IT8772E are considered compatible with the IT8721F,
-becomes available (hopefully.)
+until a datasheet becomes available (hopefully.)
 Temperatures are measured in degrees Celsius. An alarm is triggered once
 when the Overtemperature Shutdown limit is crossed.
diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42
index 66ecb9fc8246..165077121238 100644
--- a/Documentation/hwmon/jc42
+++ b/Documentation/hwmon/jc42
@@ -17,12 +17,13 @@ Supported chips:
  * Maxim MAX6604
    Datasheets:
        http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf
-  * Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP9843
+  * Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP98244, MCP9843
    Datasheets:
        http://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf
        http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf
        http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf
        http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf
+        http://ww1.microchip.com/downloads/en/DeviceDoc/22327A.pdf
  * NXP Semiconductors SE97, SE97B, SE98, SE98A
    Datasheets:
        http://www.nxp.com/documents/data_sheet/SE97.pdf
diff --git a/Documentation/hwmon/lm73 b/Documentation/hwmon/lm73
new file mode 100644
index 000000000000..8af059dcb642
--- /dev/null
+++ b/Documentation/hwmon/lm73
@@ -0,0 +1,90 @@
+Kernel driver lm73
+==================
+Supported chips:
+  * Texas Instruments LM73
+    Prefix: 'lm73'
+    Addresses scanned: I2C 0x48, 0x49, 0x4a, 0x4c, 0x4d, and 0x4e
+    Datasheet: Publicly available at the Texas Instruments website
+               http://www.ti.com/product/lm73
+Author: Guillaume Ligneul <guillaume.ligneul@gmail.com>
+Documentation: Chris Verges <kg4ysn@gmail.com>
+Description
+-----------
+The LM73 is a digital temperature sensor.  All temperature values are
+given in degrees Celsius.
+Measurement Resolution Support
+------------------------------
+The LM73 supports four resolutions, defined in terms of degrees C per
+LSB: 0.25, 0.125, 0.0625, and 0.3125.  Changing the resolution mode
+affects the conversion time of the LM73's analog-to-digital converter.
+From userspace, the desired resolution can be specified as a function of
+conversion time via the 'update_interval' sysfs attribute for the
+device.  This attribute will normalize ranges of input values to the
+maximum times defined for the resolution in the datasheet.
+    Resolution    Conv. Time    Input Range
+    (C/LSB)       (msec)        (msec)
+    --------------------------------------
+    0.25          14             0..14
+    0.125         28            15..28
+    0.0625        56            29..56
+    0.03125       112           57..infinity
+    --------------------------------------
+The following examples show how the 'update_interval' attribute can be
+used to change the conversion time:
+    $ echo 0 > update_interval
+    $ cat update_interval
+    14
+    $ cat temp1_input
+    24250
+    $ echo 22 > update_interval
+    $ cat update_interval
+    28
+    $ cat temp1_input
+    24125
+    $ echo 56 > update_interval
+    $ cat update_interval
+    56
+    $ cat temp1_input
+    24062
+    $ echo 85 > update_interval
+    $ cat update_interval
+    112
+    $ cat temp1_input
+    24031
+As shown here, the lm73 driver automatically adjusts any user input for
+'update_interval' via a step function.  Reading back the
+'update_interval' value after a write operation will confirm the
+conversion time actively in use.
+Mathematically, the resolution can be derived from the conversion time
+via the following function:
+   g(x) = 0.250 * [log(x/14) / log(2)]
+where 'x' is the output from 'update_interval' and 'g(x)' is the
+resolution in degrees C per LSB.
+Alarm Support
+-------------
+The LM73 features a simple over-temperature alarm mechanism.  This
+feature is exposed via the sysfs attributes.
+The attributes 'temp1_max_alarm' and 'temp1_min_alarm' are flags
+provided by the LM73 that indicate whether the measured temperature has
+passed the 'temp1_max' and 'temp1_min' thresholds, respectively.  These
+values _must_ be read to clear the registers on the LM73.
diff --git a/Documentation/hwmon/max34440 b/Documentation/hwmon/max34440
index 04482226db20..47651ff341ae 100644
--- a/Documentation/hwmon/max34440
+++ b/Documentation/hwmon/max34440
@@ -16,6 +16,16 @@ Supported chips:
    Prefixes: 'max34446'
    Addresses scanned: -
    Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34446.pdf
+  * Maxim MAX34460
+    PMBus 12-Channel Voltage Monitor & Sequencer
+    Prefix: 'max34460'
+    Addresses scanned: -
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34460.pdf
+  * Maxim MAX34461
+    PMBus 16-Channel Voltage Monitor & Sequencer
+    Prefix: 'max34461'
+    Addresses scanned: -
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34461.pdf
 Author: Guenter Roeck <guenter.roeck@ericsson.com>
@@ -26,6 +36,9 @@ Description
 This driver supports hardware montoring for Maxim MAX34440 PMBus 6-Channel
 Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply Manager
 and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data Logger.
+It also supports the MAX34460 and MAX34461 PMBus Voltage Monitor & Sequencers.
+The MAX34460 supports 12 voltage channels, and the MAX34461 supports 16 voltage
+channels.
 The driver is a client driver to the core PMBus driver. Please see
 Documentation/hwmon/pmbus for details on PMBus client drivers.
@@ -109,3 +122,6 @@ temp[1-8]_reset_history	Write any value to reset history.
                        temp7 and temp8 attributes only exist for MAX34440.
                        MAX34446 only supports temp[1-3].
+MAX34460 supports attribute groups in[1-12] and temp[1-5].
+MAX34461 supports attribute groups in[1-16] and temp[1-5].
diff --git a/Documentation/hwmon/max6697 b/Documentation/hwmon/max6697
new file mode 100644
index 000000000000..6594177ededa
--- /dev/null
+++ b/Documentation/hwmon/max6697
@@ -0,0 +1,58 @@
+Kernel driver max6697
+=====================
+Supported chips:
+  * Maxim MAX6581
+    Prefix: 'max6581'
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6581.pdf
+  * Maxim MAX6602
+    Prefix: 'max6602'
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6602.pdf
+  * Maxim MAX6622
+    Prefix: 'max6622'
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6622.pdf
+  * Maxim MAX6636
+    Prefix: 'max6636'
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6636.pdf
+  * Maxim MAX6689
+    Prefix: 'max6689'
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6689.pdf
+  * Maxim MAX6693
+    Prefix: 'max6693'
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6693.pdf
+  * Maxim MAX6694
+    Prefix: 'max6694'
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6694.pdf
+  * Maxim MAX6697
+    Prefix: 'max6697'
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6697.pdf
+  * Maxim MAX6698
+    Prefix: 'max6698'
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6698.pdf
+  * Maxim MAX6699
+    Prefix: 'max6699'
+    Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6699.pdf
+Author:
+    Guenter Roeck <linux@roeck-us.net>
+Description
+-----------
+This driver implements support for several MAX6697 compatible temperature sensor
+chips. The chips support one local temperature sensor plus four, six, or seven
+remote temperature sensors. Remote temperature sensors are diode-connected
+thermal transitors, except for MAX6698 which supports three diode-connected
+thermal transistors plus three thermistors in addition to the local temperature
+sensor.
+The driver provides the following sysfs attributes. temp1 is the local (chip)
+temperature, temp[2..n] are remote temperatures. The actually supported
+per-channel attributes are chip type and channel dependent.
+tempX_input      RO temperature
+tempX_max        RW temperature maximum threshold
+tempX_max_alarm  RO temperature maximum threshold alarm
+tempX_crit       RW temperature critical threshold
+tempX_crit_alarm RO temperature critical threshold alarm
+tempX_fault      RO temperature diode fault (remote sensors only)
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index 1f4dd855a299..79f8257dd790 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -722,14 +722,14 @@ add/subtract if it has been divided before the add/subtract.
 What to do if a value is found to be invalid, depends on the type of the
 sysfs attribute that is being set. If it is a continuous setting like a
 tempX_max or inX_max attribute, then the value should be clamped to its
-limits using SENSORS_LIMIT(value, min_limit, max_limit). If it is not
+limits using clamp_val(value, min_limit, max_limit). If it is not continuous
-continuous like for example a tempX_type, then when an invalid value is
+like for example a tempX_type, then when an invalid value is written,
-written, -EINVAL should be returned.
+-EINVAL should be returned.
 Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees):
        long v = simple_strtol(buf, NULL, 10) / 1000;
-        v = SENSORS_LIMIT(v, -128, 127);
+        v = clamp_val(v, -128, 127);
        /* write v to register */
 Example2, fan divider setting, valid values 2, 4 and 8:
diff --git a/Documentation/hwmon/zl6100 b/Documentation/hwmon/zl6100
index a995b41724fd..3d924b6b59e9 100644
--- a/Documentation/hwmon/zl6100
+++ b/Documentation/hwmon/zl6100
@@ -121,12 +121,26 @@ in1_max_alarm		Input voltage high alarm.
 in1_lcrit_alarm         Input voltage critical low alarm.
 in1_crit_alarm          Input voltage critical high alarm.
-in2_label               "vout1"
+in2_label               "vmon"
-in2_input               Measured output voltage.
+in2_input               Measured voltage on VMON (ZL2004) or VDRV (ZL9101M,
-in2_lcrit               Critical minimum output Voltage.
+                        ZL9117M) pin. Reported voltage is 16x the voltage on the
-in2_crit                Critical maximum output voltage.
+                        pin (adjusted internally by the chip).
-in2_lcrit_alarm         Critical output voltage critical low alarm.
+in2_lcrit               Critical minumum VMON/VDRV Voltage.
-in2_crit_alarm          Critical output voltage critical high alarm.
+in2_crit                Critical maximum VMON/VDRV voltage.
+in2_lcrit_alarm         VMON/VDRV voltage critical low alarm.
+in2_crit_alarm          VMON/VDRV voltage critical high alarm.
+                        vmon attributes are supported on ZL2004, ZL9101M,
+                        and ZL9117M only.
+inX_label               "vout1"
+inX_input               Measured output voltage.
+inX_lcrit               Critical minimum output Voltage.
+inX_crit                Critical maximum output voltage.
+inX_lcrit_alarm         Critical output voltage critical low alarm.
+inX_crit_alarm          Critical output voltage critical high alarm.
+                        X is 3 for ZL2004, ZL9101M, and ZL9117M, 2 otherwise.
 curr1_label             "iout1"
 curr1_input             Measured output current.
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index 157416e78cc4..d55b8ab2d10f 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -22,6 +22,8 @@ Supported adapters:
  * Intel Panther Point (PCH)
  * Intel Lynx Point (PCH)
  * Intel Lynx Point-LP (PCH)
+  * Intel Avoton (SOC)
+  * Intel Wellsburg (PCH)
   Datasheets: Publicly available at the Intel website
 On Intel Patsburg and later chipsets, both the normal host SMBus controller
diff --git a/Documentation/i2c/busses/i2c-ismt b/Documentation/i2c/busses/i2c-ismt
new file mode 100644
index 000000000000..737355822c0b
--- /dev/null
+++ b/Documentation/i2c/busses/i2c-ismt
@@ -0,0 +1,36 @@
+Kernel driver i2c-ismt
+Supported adapters:
+  * Intel S12xx series SOCs
+Authors:
+        Bill Brown <bill.e.brown@intel.com>
+Module Parameters
+-----------------
+* bus_speed (unsigned int)
+Allows changing of the bus speed.  Normally, the bus speed is set by the BIOS
+and never needs to be changed.  However, some SMBus analyzers are too slow for
+monitoring the bus during debug, thus the need for this module parameter.
+Specify the bus speed in kHz.
+Available bus frequency settings:
+  0  no change
+  80 kHz
+  100 kHz
+  400 kHz
+  1000 kHz
+Description
+-----------
+The S12xx series of SOCs have a pair of integrated SMBus 2.0 controllers
+targeted primarily at the microserver and storage markets.
+The S12xx series contain a pair of PCI functions.  An output of lspci will show
+something similar to the following:
+  00:13.0 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 0
+  00:13.1 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 1
diff --git a/Documentation/i2c/busses/i2c-sis630 b/Documentation/i2c/busses/i2c-sis630
index 0b9697366930..ee7943631074 100644
--- a/Documentation/i2c/busses/i2c-sis630
+++ b/Documentation/i2c/busses/i2c-sis630
@@ -4,9 +4,11 @@ Supported adapters:
  * Silicon Integrated Systems Corp (SiS)
        630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux)
        730 chipset
+        964 chipset
  * Possible other SiS chipsets ?
 Author: Alexander Malysh <amalysh@web.de>
+        Amaury Decrême <amaury.decreme@gmail.com> - SiS964 support
 Module Parameters
 -----------------
@@ -18,6 +20,7 @@ Module Parameters
 * high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
                        what your BIOS use). DANGEROUS! This should be a bit
                        faster, but freeze some systems (i.e. my Laptop).
+                        SIS630/730 chip only.
 Description
@@ -36,6 +39,12 @@ or like this:
 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
+or like this:
+00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 02)
+00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO]
+                                                        LPC Controller (rev 36)
 in your 'lspci' output , then this driver is for your chipset.
 Thank You
diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol
index d1f22618e14b..6012b12b3510 100644
--- a/Documentation/i2c/smbus-protocol
+++ b/Documentation/i2c/smbus-protocol
@@ -137,8 +137,8 @@ available for writes where the two data bytes are the other way
 around (not SMBus compliant, but very popular.)
-SMBus Process Call:  i2c_smbus_process_call()
+SMBus Process Call:
-=============================================
+===================
 This command selects a device register (through the Comm byte), sends
 16 bits of data to it, and reads 16 bits of data in return.
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index 3a94b0e6f601..6b344b516bff 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -365,8 +365,6 @@ in terms of it. Never use this function directly!
        s32 i2c_smbus_read_word_data(struct i2c_client *client, u8 command);
        s32 i2c_smbus_write_word_data(struct i2c_client *client,
                                      u8 command, u16 value);
-        s32 i2c_smbus_process_call(struct i2c_client *client,
-                                   u8 command, u16 value);
        s32 i2c_smbus_read_block_data(struct i2c_client *client,
                                      u8 command, u8 *values);
        s32 i2c_smbus_write_block_data(struct i2c_client *client,
@@ -381,6 +379,8 @@ These ones were removed from i2c-core because they had no users, but could
 be added back later if needed:
        s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value);
+        s32 i2c_smbus_process_call(struct i2c_client *client,
+                                   u8 command, u16 value);
        s32 i2c_smbus_block_process_call(struct i2c_client *client,
                                         u8 command, u8 length, u8 *values);
diff --git a/Documentation/intel_txt.txt b/Documentation/intel_txt.txt
index 849de1a78e77..91d89c540709 100644
--- a/Documentation/intel_txt.txt
+++ b/Documentation/intel_txt.txt
@@ -192,7 +192,7 @@ grub.conf needs to be modified as follows:
 The kernel option for enabling Intel TXT support is found under the
 Security top-level menu and is called "Enable Intel(R) Trusted
-Execution Technology (TXT)".  It is marked as EXPERIMENTAL and
+Execution Technology (TXT)".  It is considered EXPERIMENTAL and
 depends on the generic x86 support (to allow maximum flexibility in
 kernel build options), since the tboot code will detect whether the
 platform actually supports Intel TXT and thus whether any of the
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 2152b0e7237d..3210540f8bd3 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -179,7 +179,7 @@ Code  Seq#(hex)	Include File		Comments
 'V'     C0      media/davinci/vpfe_capture.h    conflict!
 'V'     C0      media/si4713.h          conflict!
 'W'     00-1F   linux/watchdog.h        conflict!
-'W'     00-1F   linux/wanrouter.h       conflict!
+'W'     00-1F   linux/wanrouter.h       conflict!               (pre 3.9)
 'W'     00-3F   sound/asound.h          conflict!
 'X'     all     fs/xfs/xfs_fs.h         conflict!
                and fs/xfs/linux-2.6/xfs_ioctl32.h
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 14c3f4f1b617..5198b742fde1 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1186,6 +1186,29 @@ When kbuild executes, the following steps are followed (roughly):
                clean-files += *.dtb
                DTC_FLAGS ?= -p 1024
+    dtc_cpp
+        This is just like dtc as describe above, except that the C pre-
+        processor is invoked upon the .dtsp file before compiling the result
+        with dtc.
+        In order for build dependencies to work, all files compiled using
+        dtc_cpp must use the C pre-processor's #include functionality and not
+        dtc's /include/ functionality.
+        Using the C pre-processor allows use of #define to create named
+        constants. In turn, the #defines will typically appear in a header
+        file, which may be shared with regular C code. Since the dtc language
+        represents a data structure rather than code in C syntax, similar
+        restrictions are placed on a header file included by a device tree
+        file as for a header file included by an assembly language file.
+        In particular, the C pre-processor is passed -x assembler-with-cpp,
+        which sets macro __ASSEMBLY__. __DTS__ is also set. These allow header
+        files to restrict their content to that compatible with device tree
+        source.
+        A central rule exists to create $(obj)/%.dtb from $(src)/%.dtsp;
+        architecture Makefiles do no need to explicitly write out that rule.
 --- 6.8 Custom kbuild commands
        When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 363e348bff9b..1da946548772 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -594,6 +594,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        is selected automatically. Check
                        Documentation/kdump/kdump.txt for further details.
+        crashkernel_low=size[KMG]
+                        [KNL, x86] parts under 4G.
        crashkernel=range1:size1[,range2:size2,...][@offset]
                        [KNL] Same as above, but depends on the memory
                        in the running system. The syntax of range is
@@ -1039,16 +1042,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        Claim all unknown PCI IDE storage controllers.
        idle=           [X86]
-                        Format: idle=poll, idle=mwait, idle=halt, idle=nomwait
+                        Format: idle=poll, idle=halt, idle=nomwait
                        Poll forces a polling idle loop that can slightly
                        improve the performance of waking up a idle CPU, but
                        will use a lot of power and make the system run hot.
                        Not recommended.
-                        idle=mwait: On systems which support MONITOR/MWAIT but
-                        the kernel chose to not use it because it doesn't save
-                        as much power as a normal idle loop, use the
-                        MONITOR/MWAIT idle loop anyways. Performance should be
-                        the same as idle=poll.
                        idle=halt: Halt is forced to be used for CPU idle.
                        In such case C2/C3 won't be used again.
                        idle=nomwait: Disable mwait for CPU C-states
@@ -1131,6 +1129,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        0       disables intel_idle and fall back on acpi_idle.
                        1 to 6  specify maximum depth of C-state.
+        intel_pstate=  [X86]
+                       disable
+                         Do not enable intel_pstate as the default
+                         scaling driver for the supported processors
        intremap=       [X86-64, Intel-IOMMU]
                        on      enable Interrupt Remapping (default)
                        off     disable Interrupt Remapping
@@ -1637,6 +1640,42 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        that the amount of memory usable for all allocations
                        is not too small.
+        movablemem_map=acpi
+                        [KNL,X86,IA-64,PPC] This parameter is similar to
+                        memmap except it specifies the memory map of
+                        ZONE_MOVABLE.
+                        This option inform the kernel to use Hot Pluggable bit
+                        in flags from SRAT from ACPI BIOS to determine which
+                        memory devices could be hotplugged. The corresponding
+                        memory ranges will be set as ZONE_MOVABLE.
+                        NOTE: Whatever node the kernel resides in will always
+                              be un-hotpluggable.
+        movablemem_map=nn[KMG]@ss[KMG]
+                        [KNL,X86,IA-64,PPC] This parameter is similar to
+                        memmap except it specifies the memory map of
+                        ZONE_MOVABLE.
+                        If user specifies memory ranges, the info in SRAT will
+                        be ingored. And it works like the following:
+                        - If more ranges are all within one node, then from
+                          lowest ss to the end of the node will be ZONE_MOVABLE.
+                        - If a range is within a node, then from ss to the end
+                          of the node will be ZONE_MOVABLE.
+                        - If a range covers two or more nodes, then from ss to
+                          the end of the 1st node will be ZONE_MOVABLE, and all
+                          the rest nodes will only have ZONE_MOVABLE.
+                        If memmap is specified at the same time, the
+                        movablemem_map will be limited within the memmap
+                        areas. If kernelcore or movablecore is also specified,
+                        movablemem_map will have higher priority to be
+                        satisfied. So the administrator should be careful that
+                        the amount of movablemem_map areas are not too large.
+                        Otherwise kernel won't have enough memory to start.
+                        NOTE: We don't stop users specifying the node the
+                              kernel resides in as hotpluggable so that this
+                              option can be used as a workaround of firmware
+                              bugs.
        MTD_Partition=  [MTD]
                        Format: <name>,<region-number>,<size>,<offset>
@@ -1886,10 +1925,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        wfi(ARM) instruction doesn't work correctly and not to
                        use it. This is also useful when using JTAG debugger.
-        no-hlt          [BUGS=X86-32] Tells the kernel that the hlt
-                        instruction doesn't work correctly and not to
-                        use it.
        no_file_caps    Tells the kernel not to honor file capabilities.  The
                        only way then for a file to be executed with privilege
                        is to be setuid root or executed by root.
@@ -2227,6 +2262,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                                This sorting is done to get a device
                                order compatible with older (<= 2.4) kernels.
                nobfsort        Don't sort PCI devices into breadth-first order.
+                pcie_bus_tune_off       Disable PCIe MPS (Max Payload Size)
+                                tuning and use the BIOS-configured MPS defaults.
+                pcie_bus_safe   Set every device's MPS to the largest value
+                                supported by all devices below the root complex.
+                pcie_bus_perf   Set device MPS to the largest allowable MPS
+                                based on its parent bus. Also set MRRS (Max
+                                Read Request Size) to the largest supported
+                                value (no larger than the MPS that the device
+                                or bus can support) for best performance.
+                pcie_bus_peer2peer      Set every device's MPS to 128B, which
+                                every device is guaranteed to support. This
+                                configuration allows peer-to-peer DMA between
+                                any pair of devices, possibly at the cost of
+                                reduced performance.  This also guarantees
+                                that hot-added devices will work.
                cbiosize=nn[KMG]        The fixed amount of bus space which is
                                reserved for the CardBus bridge's IO window.
                                The default value is 256 bytes.
@@ -2248,6 +2298,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                                the default.
                                off: Turn ECRC off
                                on: Turn ECRC on.
+                hpiosize=nn[KMG]        The fixed amount of bus space which is
+                                reserved for hotplug bridge's IO window.
+                                Default size is 256 bytes.
+                hpmemsize=nn[KMG]       The fixed amount of bus space which is
+                                reserved for hotplug bridge's memory window.
+                                Default size is 2 megabytes.
                realloc=        Enable/disable reallocating PCI bridge resources
                                if allocations done by BIOS are too small to
                                accommodate resources required by all child
@@ -2438,7 +2494,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        real-time workloads.  It can also improve energy
                        efficiency for asymmetric multiprocessors.
-        rcu_nocbs_poll  [KNL,BOOT]
+        rcu_nocb_poll   [KNL,BOOT]
                        Rather than requiring that offloaded CPUs
                        (specified by rcu_nocbs= above) explicitly
                        awaken the corresponding "rcuoN" kthreads,
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt
index 9d666828915a..cf7bc6cb9719 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -1398,7 +1398,7 @@ Sysfs notes:
 EXPERIMENTAL: UWB
 -----------------
-This feature is marked EXPERIMENTAL because it has not been extensively
+This feature is considered EXPERIMENTAL because it has not been extensively
 tested and validated in various ThinkPad models yet.  The feature may not
 work as expected. USE WITH CAUTION! To use this feature, you need to supply
 the experimental=1 parameter when loading the module.
diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX
index 5fefe374892f..5246090ef15c 100644
--- a/Documentation/leds/00-INDEX
+++ b/Documentation/leds/00-INDEX
@@ -6,5 +6,7 @@ leds-lp5521.txt
        - notes on how to use the leds-lp5521 driver.
 leds-lp5523.txt
        - notes on how to use the leds-lp5523 driver.
+leds-lp55xx.txt
+        - description about lp55xx common driver.
 leds-lm3556.txt
        - notes on how to use the leds-lm3556 driver.
diff --git a/Documentation/leds/leds-lp5521.txt b/Documentation/leds/leds-lp5521.txt
index 0e542ab3d4a0..270f57196339 100644
--- a/Documentation/leds/leds-lp5521.txt
+++ b/Documentation/leds/leds-lp5521.txt
@@ -17,19 +17,8 @@ lp5521:channelx, where x is 0 .. 2
 All three channels can be also controlled using the engine micro programs.
 More details of the instructions can be found from the public data sheet.
-Control interface for the engines:
+LP5521 has the internal program memory for running various LED patterns.
-x is 1 .. 3
+For the details, please refer to 'firmware' section in leds-lp55xx.txt
-enginex_mode : disabled, load, run
-enginex_load : store program (visible only in engine load mode)
-Example (start to blink the channel 2 led):
-cd   /sys/class/leds/lp5521:channel2/device
-echo "load" > engine3_mode
-echo "037f4d0003ff6000" > engine3_load
-echo "run" > engine3_mode
-stop the engine:
-echo "disabled" > engine3_mode
 sysfs contains a selftest entry.
 The test communicates with the chip and checks that
@@ -47,7 +36,7 @@ The name of each channel can be configurable.
 If the name field is not defined, the default name will be set to 'xxxx:channelN'
 (XXXX : pdata->label or i2c client name, N : channel number)
-static struct lp5521_led_config lp5521_led_config[] = {
+static struct lp55xx_led_config lp5521_led_config[] = {
        {
                .name = "red",
                .chan_nr        = 0,
@@ -81,10 +70,10 @@ static void lp5521_enable(bool state)
        /* Control of chip enable signal */
 }
-static struct lp5521_platform_data lp5521_platform_data = {
+static struct lp55xx_platform_data lp5521_platform_data = {
        .led_config     = lp5521_led_config,
        .num_channels   = ARRAY_SIZE(lp5521_led_config),
-        .clock_mode     = LP5521_CLOCK_EXT,
+        .clock_mode     = LP55XX_CLOCK_EXT,
        .setup_resources   = lp5521_setup,
        .release_resources = lp5521_release,
        .enable            = lp5521_enable,
@@ -105,47 +94,9 @@ example of update_config :
                        LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \
                        LP5521_CLK_INT)
-static struct lp5521_platform_data lp5521_pdata = {
+static struct lp55xx_platform_data lp5521_pdata = {
        .led_config = lp5521_led_config,
        .num_channels = ARRAY_SIZE(lp5521_led_config),
-        .clock_mode = LP5521_CLOCK_INT,
+        .clock_mode = LP55XX_CLOCK_INT,
        .update_config = LP5521_CONFIGS,
 };
-LED patterns : LP5521 has autonomous operation without external control.
-Pattern data can be defined in the platform data.
-example of led pattern data :
-/* RGB(50,5,0) 500ms on, 500ms off, infinite loop */
-static u8 pattern_red[] = {
-                0x40, 0x32, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
-                };
-static u8 pattern_green[] = {
-                0x40, 0x05, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
-                };
-static struct lp5521_led_pattern board_led_patterns[] = {
-        {
-                .r = pattern_red,
-                .g = pattern_green,
-                .size_r = ARRAY_SIZE(pattern_red),
-                .size_g = ARRAY_SIZE(pattern_green),
-        },
-};
-static struct lp5521_platform_data lp5521_platform_data = {
-        .led_config     = lp5521_led_config,
-        .num_channels   = ARRAY_SIZE(lp5521_led_config),
-        .clock_mode     = LP5521_CLOCK_EXT,
-        .patterns = board_led_patterns,
-        .num_patterns = ARRAY_SIZE(board_led_patterns),
-};
-Then predefined led pattern(s) can be executed via the sysfs.
-To start the pattern #1,
-# echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern
-(xxxx : i2c bus & slave address)
-To end the pattern,
-# echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern
diff --git a/Documentation/leds/leds-lp5523.txt b/Documentation/leds/leds-lp5523.txt
index c2743f59f9ac..899fdad509fe 100644
--- a/Documentation/leds/leds-lp5523.txt
+++ b/Documentation/leds/leds-lp5523.txt
@@ -27,25 +27,8 @@ c) Default
 If both fields are NULL, 'lp5523' is used by default.
 /sys/class/leds/lp5523:channelN  (N: 0 ~ 8)
-The chip provides 3 engines. Each engine can control channels without
+LP5523 has the internal program memory for running various LED patterns.
-interaction from the main CPU. Details of the micro engine code can be found
+For the details, please refer to 'firmware' section in leds-lp55xx.txt
-from the public data sheet. Leds can be muxed to different channels.
-Control interface for the engines:
-x is 1 .. 3
-enginex_mode : disabled, load, run
-enginex_load : microcode load (visible only in load mode)
-enginex_leds : led mux control (visible only in load mode)
-cd /sys/class/leds/lp5523:channel2/device
-echo "load" > engine3_mode
-echo "9d80400004ff05ff437f0000" > engine3_load
-echo "111111111" > engine3_leds
-echo "run" > engine3_mode
-sysfs contains a selftest entry. It measures each channel
-voltage level and checks if it looks reasonable. If the level is too high,
-the led is missing; if the level is too low, there is a short circuit.
 Selftest uses always the current from the platform data.
@@ -58,7 +41,7 @@ Example platform data:
 Note - chan_nr can have values between 0 and 8.
-static struct lp5523_led_config lp5523_led_config[] = {
+static struct lp55xx_led_config lp5523_led_config[] = {
        {
                .name           = "D1",
                .chan_nr        = 0,
@@ -88,10 +71,10 @@ static void lp5523_enable(bool state)
        /* Control chip enable signal */
 }
-static struct lp5523_platform_data lp5523_platform_data = {
+static struct lp55xx_platform_data lp5523_platform_data = {
        .led_config     = lp5523_led_config,
        .num_channels   = ARRAY_SIZE(lp5523_led_config),
-        .clock_mode     = LP5523_CLOCK_EXT,
+        .clock_mode     = LP55XX_CLOCK_EXT,
        .setup_resources   = lp5523_setup,
        .release_resources = lp5523_release,
        .enable            = lp5523_enable,
diff --git a/Documentation/leds/leds-lp55xx.txt b/Documentation/leds/leds-lp55xx.txt
new file mode 100644
index 000000000000..ced41868d2d1
--- /dev/null
+++ b/Documentation/leds/leds-lp55xx.txt
@@ -0,0 +1,118 @@
+LP5521/LP5523/LP55231 Common Driver
+===================================
+Authors: Milo(Woogyom) Kim <milo.kim@ti.com>
+Description
+-----------
+LP5521, LP5523/55231 have common features as below.
+  Register access via the I2C
+  Device initialization/deinitialization
+  Create LED class devices for multiple output channels
+  Device attributes for user-space interface
+  Program memory for running LED patterns
+The LP55xx common driver provides these features using exported functions.
+  lp55xx_init_device() / lp55xx_deinit_device()
+  lp55xx_register_leds() / lp55xx_unregister_leds()
+  lp55xx_regsister_sysfs() / lp55xx_unregister_sysfs()
+( Driver Structure Data )
+In lp55xx common driver, two different data structure is used.
+o lp55xx_led
+  control multi output LED channels such as led current, channel index.
+o lp55xx_chip
+  general chip control such like the I2C and platform data.
+For example, LP5521 has maximum 3 LED channels.
+LP5523/55231 has 9 output channels.
+lp55xx_chip for LP5521 ... lp55xx_led #1
+                           lp55xx_led #2
+                           lp55xx_led #3
+lp55xx_chip for LP5523 ... lp55xx_led #1
+                           lp55xx_led #2
+                                 .
+                                 .
+                           lp55xx_led #9
+( Chip Dependent Code )
+To support device specific configurations, special structure
+'lpxx_device_config' is used.
+  Maximum number of channels
+  Reset command, chip enable command
+  Chip specific initialization
+  Brightness control register access
+  Setting LED output current
+  Program memory address access for running patterns
+  Additional device specific attributes
+( Firmware Interface )
+LP55xx family devices have the internal program memory for running
+various LED patterns.
+This pattern data is saved as a file in the user-land or
+hex byte string is written into the memory through the I2C.
+LP55xx common driver supports the firmware interface.
+LP55xx chips have three program engines.
+To load and run the pattern, the programming sequence is following.
+  (1) Select an engine number (1/2/3)
+  (2) Mode change to load
+  (3) Write pattern data into selected area
+  (4) Mode change to run
+The LP55xx common driver provides simple interfaces as below.
+select_engine : Select which engine is used for running program
+run_engine    : Start program which is loaded via the firmware interface
+firmware      : Load program data
+For example, run blinking pattern in engine #1 of LP5521
+echo 1 > /sys/bus/i2c/devices/xxxx/select_engine
+echo 1 > /sys/class/firmware/lp5521/loading
+echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
+echo 0 > /sys/class/firmware/lp5521/loading
+echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+For example, run blinking pattern in engine #3 of LP55231
+echo 3 > /sys/bus/i2c/devices/xxxx/select_engine
+echo 1 > /sys/class/firmware/lp55231/loading
+echo "9d0740ff7e0040007e00a0010000" > /sys/class/firmware/lp55231/data
+echo 0 > /sys/class/firmware/lp55231/loading
+echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+To start blinking patterns in engine #2 and #3 simultaneously,
+for idx in 2 3
+do
+  echo $idx > /sys/class/leds/red/device/select_engine
+  sleep 0.1
+  echo 1 > /sys/class/firmware/lp5521/loading
+  echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
+  echo 0 > /sys/class/firmware/lp5521/loading
+done
+echo 1 > /sys/class/leds/red/device/run_engine
+Here is another example for LP5523.
+echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
+echo 1 > /sys/class/firmware/lp5523/loading
+echo "9d80400004ff05ff437f0000" > /sys/class/firmware/lp5523/data
+echo 0 > /sys/class/firmware/lp5523/loading
+echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+As soon as 'loading' is set to 0, registered callback is called.
+Inside the callback, the selected engine is loaded and memory is updated.
+To run programmed pattern, 'run_engine' attribute should be enabled.
+( 'run_engine' and 'firmware_cb' )
+The sequence of running the program data is common.
+But each device has own specific register addresses for commands.
+To support this, 'run_engine' and 'firmware_cb' are configurable in each driver.
+run_engine  : Control the selected engine
+firmware_cb : The callback function after loading the firmware is done.
+              Chip specific commands for loading and updating program memory.
diff --git a/Documentation/lockstat.txt b/Documentation/lockstat.txt
index cef00d42ed5b..dd2f7b26ca30 100644
--- a/Documentation/lockstat.txt
+++ b/Documentation/lockstat.txt
@@ -65,7 +65,7 @@ that had to wait on lock acquisition.
 - CONFIGURATION
-Lock statistics are enabled via CONFIG_LOCK_STATS.
+Lock statistics are enabled via CONFIG_LOCK_STAT.
 - USAGE
diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt
index 82761a31d64d..76d80a64bbe1 100644
--- a/Documentation/magic-number.txt
+++ b/Documentation/magic-number.txt
@@ -122,7 +122,7 @@ SLAB_C_MAGIC          0x4f17a36d  kmem_cache        mm/slab.c
 COW_MAGIC             0x4f4f4f4d  cow_header_v1     arch/um/drivers/ubd_user.c
 I810_CARD_MAGIC       0x5072696E  i810_card         sound/oss/i810_audio.c
 TRIDENT_CARD_MAGIC    0x5072696E  trident_card      sound/oss/trident.c
-ROUTER_MAGIC          0x524d4157  wan_device        include/linux/wanrouter.h
+ROUTER_MAGIC          0x524d4157  wan_device        [in wanrouter.h pre 3.9]
 SCC_MAGIC             0x52696368  gs_port           drivers/char/scc.h
 SAVEKMSG_MAGIC1       0x53415645  savekmsg          arch/*/amiga/config.c
 GDA_MAGIC             0x58464552  gda               arch/mips/include/asm/sn/gda.h
diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt
index 802875413873..77bd0a42f19d 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -336,7 +336,7 @@ Calls to media_entity_pipeline_start() can be nested. The pipeline pointer must
 be identical for all nested calls to the function.
 media_entity_pipeline_start() may return an error. In that case, it will
-clean up any the changes it did by itself.
+clean up any of the changes it did by itself.
 When stopping the stream, drivers must notify the entities with
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 3c4e1b3b80a1..fa5d8a9ae205 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1685,6 +1685,7 @@ explicit lock operations, described later).  These include:
        xchg();
        cmpxchg();
+        atomic_xchg();
        atomic_cmpxchg();
        atomic_inc_return();
        atomic_dec_return();
diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt
new file mode 100644
index 000000000000..abc13c394738
--- /dev/null
+++ b/Documentation/namespaces/resource-control.txt
@@ -0,0 +1,14 @@
+There are a lot of kinds of objects in the kernel that don't have
+individual limits or that have limits that are ineffective when a set
+of processes is allowed to switch user ids.  With user namespaces
+enabled in a kernel for people who don't trust their users or their
+users programs to play nice this problems becomes more acute.
+Therefore it is recommended that memory control groups be enabled in
+kernels that enable user namespaces, and it is further recommended
+that userspace configure memory control groups to limit how much
+memory user's they don't trust to play nice can use.
+Memory control groups can be configured by installing the libcgroup
+package present on most distros editing /etc/cgrules.conf,
+/etc/cgconfig.conf and setting up libpam-cgroup.
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 2cc3c7733a2f..258d9b92c36f 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -52,8 +52,6 @@ de4x5.txt
        - the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver
 decnet.txt
        - info on using the DECnet networking layer in Linux.
-depca.txt
-        - the Digital DEPCA/EtherWORKS DE1?? and DE2?? LANCE Ethernet driver
 dl2k.txt
        - README for D-Link DL2000-based Gigabit Ethernet Adapters (dl2k.ko).
 dm9000.txt
@@ -72,8 +70,6 @@ e1000e.txt
        - README for the Intel Gigabit Ethernet Driver (e1000e).
 eql.txt
        - serial IP load balancing
-ewrk3.txt
-        - the Digital EtherWORKS 3 DE203/4/5 Ethernet driver
 fib_trie.txt
        - Level Compressed Trie (LC-trie) notes: a structure for routing.
 filter.txt
@@ -126,8 +122,6 @@ ltpc.txt
        - the Apple or Farallon LocalTalk PC card driver
 mac80211-injection.txt
        - HOWTO use packet injection with mac80211
-multicast.txt
-        - Behaviour of cards under Multicast
 multiqueue.txt
        - HOWTO for multiqueue network device support.
 netconsole.txt
diff --git a/Documentation/networking/DLINK.txt b/Documentation/networking/DLINK.txt
deleted file mode 100644
index 55d24433d151..000000000000
--- a/Documentation/networking/DLINK.txt
+++ /dev/null
@@ -1,203 +0,0 @@
-Released 1994-06-13
-        CONTENTS:
-        1. Introduction.
-        2. License.
-        3. Files in this release.
-        4. Installation.
-        5. Problems and tuning.
-        6. Using the drivers with earlier releases.
-        7. Acknowledgments.
-        1. INTRODUCTION.
-        This is a set of Ethernet drivers for the D-Link DE-600/DE-620
-        pocket adapters, for the parallel port on a Linux based machine.
-        Some adapter "clones" will also work.  Xircom is _not_ a clone...
-        These drivers _can_ be used as loadable modules,
-        and were developed for use on Linux 1.1.13 and above.
-        For use on Linux 1.0.X, or earlier releases, see below.
-        I have used these drivers for NFS, ftp, telnet and X-clients on
-        remote machines. Transmissions with ftp seems to work as
-        good as can be expected (i.e. > 80k bytes/sec) from a
-        parallel port...:-)  Receive speeds will be about 60-80% of this.
-        Depending on your machine, somewhat higher speeds can be achieved.
-        All comments/fixes to Bjorn Ekwall (bj0rn@blox.se).
-        2. LICENSE.
-        This program is free software; you can redistribute it
-        and/or modify it under the terms of the GNU General Public
-        License as published by the Free Software Foundation; either
-        version 2, or (at your option) any later version.
-        This program is distributed in the hope that it will be
-        useful, but WITHOUT ANY WARRANTY; without even the implied
-        warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
-        PURPOSE. See the GNU General Public License for more
-        details.
-        You should have received a copy of the GNU General Public
-        License along with this program; if not, write to the Free
-        Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
-        02139, USA.
-        3. FILES IN THIS RELEASE.
-        README.DLINK  This file.
-        de600.c       The Source (may it be with You :-) for the DE-600
-        de620.c       ditto for the DE-620
-        de620.h       Macros for de620.c
-        If you are upgrading from the d-link tar release, there will
-        also be a "dlink-patches" file that will patch Linux 1.1.18:
-                linux/drivers/net/Makefile
-                linux/drivers/net/CONFIG
-                linux/drivers/net/MODULES
-                linux/drivers/net/Space.c
-                linux/config.in
-        Apply the patch by:
-        "cd /usr/src; patch -p0 < linux/drivers/net/dlink-patches"
-        The old source, "linux/drivers/net/d_link.c", can be removed.
-        4. INSTALLATION.
-        o Get the latest net binaries, according to current net.wisdom.
-        o Read the NET-2 and Ethernet HOWTOs and modify your setup.
-        o If your parallel port has a strange address or irq,
-          modify "linux/drivers/net/CONFIG" accordingly, or adjust
-          the parameters in the "tuning" section in the sources.
-        If you are going to use the drivers as loadable modules, do _not_
-        enable them while doing "make config", but instead make sure that
-        the drivers are included in "linux/drivers/net/MODULES".
-        If you are _not_ going to use the driver(s) as loadable modules,
-        but instead have them included in the kernel, remember to enable
-        the drivers while doing "make config".
-        o To include networking and DE600/DE620 support in your kernel:
-          # cd /linux
-          (as modules:)
-          #  make config (answer yes on CONFIG_NET and CONFIG_INET)
-          (else included in the kernel:)
-          #  make config (answer yes on CONFIG _NET, _INET and _DE600 or _DE620)
-          # make clean
-          # make zImage (or whatever magic you usually do)
-        o I use lilo to boot multiple kernels, so that I at least
-          can have one working kernel :-). If you do too, append
-          these lines to /etc/lilo/config:
-                image = /linux/zImage
-                label = newlinux
-                root = /dev/hda2 (or whatever YOU have...)
-          # /etc/lilo/install
-        o Do "sync" and reboot the new kernel with a D-Link
-          DE-600/DE-620 pocket adapter connected.
-        o The adapter can be configured with ifconfig eth?
-          where the actual number is decided by the kernel
-          when the drivers are initialized.
-        5. "PROBLEMS" AND TUNING,
-        o If you see error messages from the driver, and if the traffic
-          stops on the adapter, try to do "ifconfig" and "route" once
-          more, just as in "rc.inet1".  This should take care of most
-          problems, including effects from power loss, or adapters that
-          aren't connected to the printer port in some way or another.
-          You can somewhat change the behaviour by enabling/disabling
-          the macro  SHUTDOWN_WHEN_LOST  in the "tuning" section.
-          For the DE-600 there is another macro, CHECK_LOST_DE600,
-          that you might want to read about in the "tuning" section.
-        o Some machines have trouble handling the parallel port and
-          the adapter at high speed. If you experience problems:
-          DE-600:
-          - The adapter is not recognized at boot, i.e. an Ethernet
-            address of 00:80:c8:... is not shown, try to add another
-              "; SLOW_DOWN_IO"
-            at DE600_SLOW_DOWN in the "tuning" section. As a last resort,
-            uncomment: "#define REALLY_SLOW_IO" (see <asm/io.h> for hints).
-          - You experience "timeout" messages: first try to add another
-              "; SLOW_DOWN_IO"
-            at DE600_SLOW_DOWN in the "tuning" section, _then_ try to
-            increase the value (original value: 5) at
-            "if (tickssofar < 5)" near line 422.
-          DE-620:
-          - Your parallel port might be "sluggish".  To cater for
-            this, there are the macros LOWSPEED and READ_DELAY/WRITE_DELAY
-            in the "tuning" section. Your first step should be to enable
-            LOWSPEED, and after that you can "tune" the XXX_DELAY values.
-        o If the adapter _is_ recognized at boot but you get messages
-          about "Network Unreachable", then the problem is probably
-          _not_ with the driver.  Check your net configuration instead
-          (ifconfig and route) in "rc.inet1".
-        o There is some rudimentary support for debugging, look at
-          the source. Use "-DDE600_DEBUG=3" or "-DDE620_DEBUG=3"
-          when compiling, or include it in "linux/drivers/net/CONFIG".
-          IF YOU HAVE PROBLEMS YOU CAN'T SOLVE: PLEASE COMPILE THE DRIVER
-          WITH DEBUGGING ENABLED, AND SEND ME THE RESULTING OUTPUT!
-        6. USING THE DRIVERS WITH EARLIER RELEASES.
-        The later 1.1.X releases of the Linux kernel include some
-        changes in the networking layer (a.k.a. NET3). This affects
-        these drivers in a few places.  The hints that follow are
-        _not_ tested by me, since I don't have the disk space to keep
-        all releases on-line.
-        Known needed changes to date:
-        - release patchfile: some patches will fail, but they should
-          be easy to apply "by hand", since they are trivial.
-          (Space.c: d_link_init() is now called de600_probe())
-        - de600.c: change  "mark_bh(NET_BH)" to  "mark_bh(INET_BH)".
-        - de620.c: (maybe) change the code around "netif_rx(skb);" to be
-                   similar to the code around "dev_rint(...)" in de600.c
-        7. ACKNOWLEDGMENTS.
-        These drivers wouldn't have been done without the base
-        (and support) from Ross Biro, and D-Link Systems Inc.
-        The driver relies upon GPL-ed source from D-Link Systems Inc.
-        and from Russel Nelson at Crynwr Software <nelson@crynwr.com>.
-        Additional input also from:
-        Donald Becker <becker@super.org>, Alan Cox <A.Cox@swansea.ac.uk>
-        and Fred N. van Kempen <waltje@uWalt.NL.Mugnet.ORG>
-        DE-600 alpha release primary victim^H^H^H^H^H^Htester:
-        - Erik Proper <erikp@cs.kun.nl>.
-        Good input also from several users, most notably
-        - Mark Burton <markb@ordern.demon.co.uk>.
-        DE-620 alpha release victims^H^H^H^H^H^H^Htesters:
-        - J. Joshua Kopper <kopper@rtsg.mot.com>
-        - Olav Kvittem <Olav.Kvittem@uninett.no>
-        - Germano Caronni <caronni@nessie.cs.id.ethz.ch>
-        - Jeremy Fitzhardinge <jeremy@suite.sw.oz.au>
-        Happy hacking!
-        Bjorn Ekwall == bj0rn@blox.se
diff --git a/Documentation/networking/LICENSE.qlcnic b/Documentation/networking/LICENSE.qlcnic
index e7fb2c6023bc..2ae3b64983ab 100644
--- a/Documentation/networking/LICENSE.qlcnic
+++ b/Documentation/networking/LICENSE.qlcnic
@@ -1,4 +1,4 @@
-Copyright (c) 2009-2011 QLogic Corporation
+Copyright (c) 2009-2013 QLogic Corporation
 QLogic Linux qlcnic NIC Driver
 You may modify and redistribute the device driver code under the
diff --git a/Documentation/networking/cs89x0.txt b/Documentation/networking/cs89x0.txt
index c725d33b316f..0e190180eec8 100644
--- a/Documentation/networking/cs89x0.txt
+++ b/Documentation/networking/cs89x0.txt
@@ -36,7 +36,6 @@ TABLE OF CONTENTS
    4.1 Compiling the Driver as a Loadable Module
    4.2 Compiling the driver to support memory mode
    4.3 Compiling the driver to support Rx DMA 
-    4.4 Compiling the Driver into the Kernel
 5.0 TESTING AND TROUBLESHOOTING
    5.1 Known Defects and Limitations
@@ -364,84 +363,6 @@ The compile-time optionality for DMA was removed in the 2.3 kernel
 series.  DMA support is now unconditionally part of the driver.  It is
 enabled by the 'use_dma=1' module option.
-4.4 COMPILING THE DRIVER INTO THE KERNEL
-If your Linux distribution already has support for the cs89x0 driver
-then simply copy the source file to the /usr/src/linux/drivers/net
-directory to replace the original ones and run the make utility to
-rebuild the kernel.  See Step 3 for rebuilding the kernel.
-If your Linux does not include the cs89x0 driver, you need to edit three 
-configuration files, copy the source file to the /usr/src/linux/drivers/net
-directory, and then run the make utility to rebuild the kernel.
-1. Edit the following configuration files by adding the statements as
-indicated.  (When possible, try to locate the added text to the section of the
-file containing similar statements).
-a.) In /usr/src/linux/drivers/net/Config.in, add:
-tristate 'CS89x0 support' CONFIG_CS89x0
-Example:
-     if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-       tristate 'ICL EtherTeam 16i/32 support' CONFIG_ETH16I
-     fi
-     tristate 'CS89x0 support' CONFIG_CS89x0
-     tristate 'NE2000/NE1000 support' CONFIG_NE2000
-     if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-       tristate 'NI5210 support' CONFIG_NI52
-b.) In /usr/src/linux/drivers/net/Makefile, add the following lines: 
-ifeq ($(CONFIG_CS89x0),y)
-L_OBJS += cs89x0.o
-else
-  ifeq ($(CONFIG_CS89x0),m)
-  M_OBJS += cs89x0.o
-  endif
-endif
-c.) In /linux/drivers/net/Space.c file, add the line:
-extern int cs89x0_probe(struct device *dev);
-Example:
- extern int ultra_probe(struct device *dev);
- extern int wd_probe(struct device *dev);
- extern int el2_probe(struct device *dev);
- extern int cs89x0_probe(struct device *dev);
- extern int ne_probe(struct device *dev);
- extern int hp_probe(struct device *dev);
- extern int hp_plus_probe(struct device *dev);
-Also add:
- #ifdef CONFIG_CS89x0
-        { cs89x0_probe,0 },
- #endif
-2.) Copy the driver source files (cs89x0.c and cs89x0.h) 
-into the /usr/src/linux/drivers/net directory.
-3.) Go to /usr/src/linux directory and run 'make config' followed by 'make' 
-(or make bzImage) to rebuild the kernel. 
-4.) Use the DOS 'setup' utility to disable plug and play on the NIC.
 5.0 TESTING AND TROUBLESHOOTING
 ===============================================================================
diff --git a/Documentation/networking/depca.txt b/Documentation/networking/depca.txt
deleted file mode 100644
index 24c6b26e5658..000000000000
--- a/Documentation/networking/depca.txt
+++ /dev/null
@@ -1,92 +0,0 @@
-DE10x
-=====
-Memory Addresses:
-        SW1     SW2     SW3     SW4
-64K     on      on      on      on      d0000   dbfff
-        off     on      on      on      c0000   cbfff
-        off     off     on      on      e0000   ebfff
-32K     on      on      off     on      d8000   dbfff
-        off     on      off     on      c8000   cbfff
-        off     off     off     on      e8000   ebfff
-DBR ROM on      on                      dc000   dffff
-        off     on                      cc000   cffff
-        off     off                     ec000   effff
-Note  that the 2K  mode   is set  by   SW3/SW4  on/off or  off/off.  Address
-assignment is through the RBSA register.
-I/O Address:
-        SW5
-0x300   on
-0x200   off
-Remote Boot:
-        SW6
-Disable on
-Enable  off
-Remote Boot Timeout:
-        SW7
-2.5min  on
-30s     off
-IRQ:
-        SW8     SW9     SW10    SW11    SW12
-2       on      off     off     off     off
-3       off     on      off     off     off
-4       off     off     on      off     off
-5       off     off     off     on      off
-7       off     off     off     off     on
-DE20x
-=====
-Memory Size:
-        SW3     SW4
-64K     on      on
-32K     off     on
-2K      on      off
-2K      off     off
-Start Addresses:
-        SW1     SW2     SW3     SW4
-64K     on      on      on      on      c0000   cffff
-        on      off     on      on      d0000   dffff
-        off     on      on      on      e0000   effff
-32K     on      on      off     off     c8000   cffff
-        on      off     off     off     d8000   dffff
-        off     on      off     off     e8000   effff
-Illegal off     off      -       -        -       -
-I/O Address:
-        SW5
-0x300   on
-0x200   off
-Remote Boot:
-        SW6
-Disable on
-Enable  off
-Remote Boot Timeout:
-        SW7
-2.5min  on
-30s     off
-IRQ:
-        SW8     SW9     SW10    SW11    SW12
-5       on      off     off     off     off
-9       off     on      off     off     off
-10      off     off     on      off     off
-11      off     off     off     on      off
-15      off     off     off     off     on
diff --git a/Documentation/networking/ewrk3.txt b/Documentation/networking/ewrk3.txt
deleted file mode 100644
index 90e9e5f16e6b..000000000000
--- a/Documentation/networking/ewrk3.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-The EtherWORKS 3  driver in this distribution is  designed to  work with all
-kernels   >  1.1.33   (approx)  and  includes  tools   in  the  'ewrk3tools'
-subdirectory   to  allow  set   up of   the   card,  similar  to  the  MSDOS
-'NICSETUP.EXE' tools provided on  the DOS drivers  disk (type 'make' in that
-subdirectory to make the tools).
-The supported  cards are DE203,  DE204 and DE205.  All   other cards are NOT
-supported - refer to 'depca.c' for running the LANCE based network cards and
-'de4x5.c'  for the  DIGITAL   Semiconductor PCI  chip  based  adapters  from
-Digital.
-The ability to load  this driver as a  loadable module has been included and
-used extensively  during the driver  development (to save those  long reboot
-sequences). To utilise this ability, you have to do 8 things:
-    0) have a copy of the loadable modules code installed on your system.
-    1) copy ewrk3.c from the  /linux/drivers/net directory to your favourite
-    temporary directory.
-    2) edit the  source code near  line 1898 to reflect  the I/O address and
-    IRQ you're using.
-    3) compile  ewrk3.c, but include -DMODULE in  the command line to ensure
-    that the correct bits are compiled (see end of source code).
-    4) if you are wanting to add a new  card, goto 5. Otherwise, recompile a
-    kernel with the ewrk3 configuration turned off and reboot.
-    5) insmod ewrk3.o
-          [Alan Cox: Changed this so you can insmod ewrk3.o irq=x io=y]
-          [Adam Kropelin: Multiple cards now supported by irq=x1,x2 io=y1,y2]
-    6) run the net startup bits for your new eth?? interface manually 
-    (usually /etc/rc.inet[12] at boot time). 
-    7) enjoy!
-    Note that autoprobing is not allowed in loadable modules - the system is
-    already up and running and you're messing with interrupts.
-    To unload a module, turn off the associated interface 
-    'ifconfig eth?? down' then 'rmmod ewrk3'.
-The performance we've  achieved so far  has been measured through the 'ttcp'
-tool   at 975kB/s.  This  measures  the  total  TCP  stack performance which
-includes the   card,  so don't  expect   to get   much nearer  the  1.25MB/s
-theoretical Ethernet rate.
-Enjoy!
-Dave
diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt
index bbf2005270b5..cdb3e40b9d14 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -17,12 +17,12 @@ creating filters.
 LSF is much simpler than BPF. One does not have to worry about
 devices or anything like that. You simply create your filter
-code, send it to the kernel via the SO_ATTACH_FILTER ioctl and
+code, send it to the kernel via the SO_ATTACH_FILTER option and
 if your filter code passes the kernel check on it, you then
 immediately begin filtering data on that socket.
 You can also detach filters from your socket via the
-SO_DETACH_FILTER ioctl. This will probably not be used much
+SO_DETACH_FILTER option. This will probably not be used much
 since when you close a socket that has a filter on it the
 filter is automagically removed. The other less common case
 may be adding a different filter on the same socket where you had another
@@ -31,12 +31,19 @@ the old one and placing your new one in its place, assuming your
 filter has passed the checks, otherwise if it fails the old filter
 will remain on that socket.
+SO_LOCK_FILTER option allows to lock the filter attached to a
+socket. Once set, a filter cannot be removed or changed. This allows
+one process to setup a socket, attach a filter, lock it then drop
+privileges and be assured that the filter will be kept until the
+socket is closed.
 Examples
 ========
 Ioctls-
 setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &Filter, sizeof(Filter));
 setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &value, sizeof(value));
+setsockopt(sockfd, SOL_SOCKET, SO_LOCK_FILTER, &value, sizeof(value));
 See the BSD bpf.4 manpage and the BSD Packet Filter paper written by
 Steven McCanne and Van Jacobson of Lawrence Berkeley Laboratory.
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index dbca66182089..dc2dc87d2557 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -26,6 +26,11 @@ route/max_size - INTEGER
        Maximum number of routes allowed in the kernel.  Increase
        this when using large numbers of interfaces and/or routes.
+neigh/default/gc_thresh1 - INTEGER
+        Minimum number of entries to keep.  Garbage collector will not
+        purge entries if there are fewer than this number.
+        Default: 256
 neigh/default/gc_thresh3 - INTEGER
        Maximum number of neighbor entries allowed.  Increase this
        when using large numbers of interfaces and when communicating
@@ -125,17 +130,6 @@ somaxconn - INTEGER
        Defaults to 128.  See also tcp_max_syn_backlog for additional tuning
        for TCP sockets.
-tcp_abc - INTEGER
-        Controls Appropriate Byte Count (ABC) defined in RFC3465.
-        ABC is a way of increasing congestion window (cwnd) more slowly
-        in response to partial acknowledgments.
-        Possible values are:
-                0 increase cwnd once per acknowledgment (no ABC)
-                1 increase cwnd once per acknowledgment of full sized segment
-                2 allow increase cwnd by two if acknowledgment is
-                  of two segments to compensate for delayed acknowledgments.
-        Default: 0 (off)
 tcp_abort_on_overflow - BOOLEAN
        If listening service is too slow to accept new connections,
        reset them. Default state is FALSE. It means that if overflow
@@ -214,7 +208,8 @@ tcp_ecn - INTEGER
        congestion before having to drop packets.
        Possible values are:
                0 Disable ECN.  Neither initiate nor accept ECN.
-                1 Always request ECN on outgoing connection attempts.
+                1 Enable ECN when requested by incoming connections and
+                  also request ECN on outgoing connection attempts.
                2 Enable ECN when requested by incoming connections
                  but do not request ECN on outgoing connections.
        Default: 2
diff --git a/Documentation/networking/multicast.txt b/Documentation/networking/multicast.txt
deleted file mode 100644
index b06c8c69266f..000000000000
--- a/Documentation/networking/multicast.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-Behaviour of Cards Under Multicast
-==================================
-This is how they currently behave, not what the hardware can do--for example,
-the Lance driver doesn't use its filter, even though the code for loading
-it is in the DEC Lance-based driver.
-The following are requirements for multicasting 
-----------------------------------------------
-AppleTalk       Multicast       hardware filtering not important but
-                                 avoid cards only doing promisc
-IP-Multicast    Multicast       hardware filters really help
-IP-MRoute       AllMulti        hardware filters are of no help
-Board           Multicast       AllMulti        Promisc         Filter
------------------------------------------------------------------------
-3c501           YES             YES             YES             Software
-3c503           YES             YES             YES             Hardware
-3c505           YES             NO              YES             Hardware
-3c507           NO              NO              NO              N/A
-3c509           YES             YES             YES             Software
-3c59x           YES             YES             YES             Software
-ac3200          YES             YES             YES             Hardware
-apricot         YES             PROMISC         YES             Hardware
-arcnet          NO              NO              NO              N/A
-at1700          PROMISC         PROMISC         YES             Software
-atp             PROMISC         PROMISC         YES             Software
-cs89x0          YES             YES             YES             Software
-de4x5           YES             YES             YES             Hardware
-de600           NO              NO              NO              N/A
-de620           PROMISC         PROMISC         YES             Software
-depca           YES             PROMISC         YES             Hardware
-dmfe            YES             YES             YES             Software(*)
-e2100           YES             YES             YES             Hardware
-eepro           YES             PROMISC         YES             Hardware
-eexpress        NO              NO              NO              N/A
-ewrk3           YES             PROMISC         YES             Hardware
-hp-plus         YES             YES             YES             Hardware
-hp              YES             YES             YES             Hardware
-hp100           YES             YES             YES             Hardware
-ibmtr           NO              NO              NO              N/A
-ioc3-eth        YES             YES             YES             Hardware
-lance           YES             YES             YES             Software(#)
-ne              YES             YES             YES             Hardware
-ni52            <------------------ Buggy ------------------>
-ni65            YES             YES             YES             Software(#)
-seeq            NO              NO              NO              N/A
-sgiseek         <------------------ Buggy ------------------>
-smc-ultra       YES             YES             YES             Hardware
-sunlance        YES             YES             YES             Hardware
-tulip           YES             YES             YES             Hardware
-wavelan         YES             PROMISC         YES             Hardware
-wd              YES             YES             YES             Hardware
-xirc2ps_cs      YES             YES             YES             Hardware
-znet            YES             YES             YES             Software
-PROMISC = This multicast mode is in fact promiscuous mode. Avoid using
-cards who go PROMISC on any multicast in a multicast kernel.
-(#) = Hardware multicast support is not used yet.
-(*) = Hardware support for Davicom 9132 chipset only.
diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt
index 2e9e0ae2cd45..a5d574a9ae09 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -1,9 +1,10 @@
 started by Ingo Molnar <mingo@redhat.com>, 2001.09.17
 2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003
+IPv6 support by Cong Wang <xiyou.wangcong@gmail.com>, Jan 1 2013
 Please send bug reports to Matt Mackall <mpm@selenic.com>
-and Satyam Sharma <satyam.sharma@gmail.com>
+Satyam Sharma <satyam.sharma@gmail.com>, and Cong Wang <xiyou.wangcong@gmail.com>
 Introduction:
 =============
@@ -41,6 +42,10 @@ Examples:
 insmod netconsole netconsole=@/,@10.0.0.2/
+  or using IPv6
+ insmod netconsole netconsole=@/,@fd00:1:2:3::1/
 It also supports logging to multiple remote agents by specifying
 parameters for the multiple agents separated by semicolons and the
 complete string enclosed in "quotes", thusly:
diff --git a/Documentation/networking/nf_conntrack-sysctl.txt b/Documentation/networking/nf_conntrack-sysctl.txt
new file mode 100644
index 000000000000..70da5086153d
--- /dev/null
+++ b/Documentation/networking/nf_conntrack-sysctl.txt
@@ -0,0 +1,176 @@
+/proc/sys/net/netfilter/nf_conntrack_* Variables:
+nf_conntrack_acct - BOOLEAN
+        0 - disabled (default)
+        not 0 - enabled
+        Enable connection tracking flow accounting. 64-bit byte and packet
+        counters per flow are added.
+nf_conntrack_buckets - INTEGER (read-only)
+        Size of hash table. If not specified as parameter during module
+        loading, the default size is calculated by dividing total memory
+        by 16384 to determine the number of buckets but the hash table will
+        never have fewer than 32 or more than 16384 buckets.
+nf_conntrack_checksum - BOOLEAN
+        0 - disabled
+        not 0 - enabled (default)
+        Verify checksum of incoming packets. Packets with bad checksums are
+        in INVALID state. If this is enabled, such packets will not be
+        considered for connection tracking.
+nf_conntrack_count - INTEGER (read-only)
+        Number of currently allocated flow entries.
+nf_conntrack_events - BOOLEAN
+        0 - disabled
+        not 0 - enabled (default)
+        If this option is enabled, the connection tracking code will
+        provide userspace with connection tracking events via ctnetlink.
+nf_conntrack_events_retry_timeout - INTEGER (seconds)
+        default 15
+        This option is only relevant when "reliable connection tracking
+        events" are used.  Normally, ctnetlink is "lossy", that is,
+        events are normally dropped when userspace listeners can't keep up.
+        Userspace can request "reliable event mode".  When this mode is
+        active, the conntrack will only be destroyed after the event was
+        delivered.  If event delivery fails, the kernel periodically
+        re-tries to send the event to userspace.
+        This is the maximum interval the kernel should use when re-trying
+        to deliver the destroy event.
+        A higher number means there will be fewer delivery retries and it
+        will take longer for a backlog to be processed.
+nf_conntrack_expect_max - INTEGER
+        Maximum size of expectation table.  Default value is
+        nf_conntrack_buckets / 256. Minimum is 1.
+nf_conntrack_frag6_high_thresh - INTEGER
+        default 262144
+        Maximum memory used to reassemble IPv6 fragments.  When
+        nf_conntrack_frag6_high_thresh bytes of memory is allocated for this
+        purpose, the fragment handler will toss packets until
+        nf_conntrack_frag6_low_thresh is reached.
+nf_conntrack_frag6_low_thresh - INTEGER
+        default 196608
+        See nf_conntrack_frag6_low_thresh
+nf_conntrack_frag6_timeout - INTEGER (seconds)
+        default 60
+        Time to keep an IPv6 fragment in memory.
+nf_conntrack_generic_timeout - INTEGER (seconds)
+        default 600
+        Default for generic timeout.  This refers to layer 4 unknown/unsupported
+        protocols.
+nf_conntrack_helper - BOOLEAN
+        0 - disabled
+        not 0 - enabled (default)
+        Enable automatic conntrack helper assignment.
+nf_conntrack_icmp_timeout - INTEGER (seconds)
+        default 30
+        Default for ICMP timeout.
+nf_conntrack_icmpv6_timeout - INTEGER (seconds)
+        default 30
+        Default for ICMP6 timeout.
+nf_conntrack_log_invalid - INTEGER
+        0   - disable (default)
+        1   - log ICMP packets
+        6   - log TCP packets
+        17  - log UDP packets
+        33  - log DCCP packets
+        41  - log ICMPv6 packets
+        136 - log UDPLITE packets
+        255 - log packets of any protocol
+        Log invalid packets of a type specified by value.
+nf_conntrack_max - INTEGER
+        Size of connection tracking table.  Default value is
+        nf_conntrack_buckets value * 4.
+nf_conntrack_tcp_be_liberal - BOOLEAN
+        0 - disabled (default)
+        not 0 - enabled
+        Be conservative in what you do, be liberal in what you accept from others.
+        If it's non-zero, we mark only out of window RST segments as INVALID.
+nf_conntrack_tcp_loose - BOOLEAN
+        0 - disabled
+        not 0 - enabled (default)
+        If it is set to zero, we disable picking up already established
+        connections.
+nf_conntrack_tcp_max_retrans - INTEGER
+        default 3
+        Maximum number of packets that can be retransmitted without
+        received an (acceptable) ACK from the destination. If this number
+        is reached, a shorter timer will be started.
+nf_conntrack_tcp_timeout_close - INTEGER (seconds)
+        default 10
+nf_conntrack_tcp_timeout_close_wait - INTEGER (seconds)
+        default 60
+nf_conntrack_tcp_timeout_established - INTEGER (seconds)
+        default 432000 (5 days)
+nf_conntrack_tcp_timeout_fin_wait - INTEGER (seconds)
+        default 120
+nf_conntrack_tcp_timeout_last_ack - INTEGER (seconds)
+        default 30
+nf_conntrack_tcp_timeout_max_retrans - INTEGER (seconds)
+        default 300
+nf_conntrack_tcp_timeout_syn_recv - INTEGER (seconds)
+        default 60
+nf_conntrack_tcp_timeout_syn_sent - INTEGER (seconds)
+        default 120
+nf_conntrack_tcp_timeout_time_wait - INTEGER (seconds)
+        default 120
+nf_conntrack_tcp_timeout_unacknowledged - INTEGER (seconds)
+        default 300
+nf_conntrack_timestamp - BOOLEAN
+        0 - disabled (default)
+        not 0 - enabled
+        Enable connection tracking flow timestamping.
+nf_conntrack_udp_timeout - INTEGER (seconds)
+        default 30
+nf_conntrack_udp_timeout_stream2 - INTEGER (seconds)
+        default 180
+        This extended timeout will be used in case there is an UDP stream
+        detected.
diff --git a/Documentation/networking/operstates.txt b/Documentation/networking/operstates.txt
index 1a77a3cfae54..97694572338b 100644
--- a/Documentation/networking/operstates.txt
+++ b/Documentation/networking/operstates.txt
@@ -88,6 +88,10 @@ set this flag. On netif_carrier_off(), the scheduler stops sending
 packets. The name 'carrier' and the inversion are historical, think of
 it as lower layer.
+Note that for certain kind of soft-devices, which are not managing any
+real hardware, there is possible to set this bit from userpsace.
+One should use TVL IFLA_CARRIER to do so.
 netif_carrier_ok() can be used to query that bit.
 __LINK_STATE_DORMANT, maps to IFF_DORMANT:
diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt
index 95e5f5985a2a..d5b1a3935245 100644
--- a/Documentation/networking/phy.txt
+++ b/Documentation/networking/phy.txt
@@ -103,7 +103,7 @@ Letting the PHY Abstraction Layer do Everything
 
 Now, to connect, just call this function:
 
-   phydev = phy_connect(dev, phy_name, &adjust_link, flags, interface);
+   phydev = phy_connect(dev, phy_name, &adjust_link, interface);
 phydev is a pointer to the phy_device structure which represents the PHY.  If
 phy_connect is successful, it will return the pointer.  dev, here, is the
@@ -113,7 +113,9 @@ Letting the PHY Abstraction Layer do Everything
 current state, though the PHY will not yet be truly operational at this
 point.
- flags is a u32 which can optionally contain phy-specific flags.
+ PHY-specific flags should be set in phydev->dev_flags prior to the call
+ to phy_connect() such that the underlying PHY driver can check for flags
+ and perform specific operations based on them.
 This is useful if the system has put hardware restrictions on
 the PHY/controller, of which the PHY needs to be aware.
@@ -185,11 +187,10 @@ Doing it all yourself
   start, or disables then frees them for stop.
 struct phy_device * phy_attach(struct net_device *dev, const char *phy_id,
-                 u32 flags, phy_interface_t interface);
+                 phy_interface_t interface);
   Attaches a network device to a particular PHY, binding the PHY to a generic
-   driver if none was found during bus initialization.  Passes in
+   driver if none was found during bus initialization.
-   any phy-specific flags as needed.
 int phy_start_aneg(struct phy_device *phydev);
   
diff --git a/Documentation/nfc/nfc-hci.txt b/Documentation/nfc/nfc-hci.txt
index 89a339c9b079..0686c9e211c2 100644
--- a/Documentation/nfc/nfc-hci.txt
+++ b/Documentation/nfc/nfc-hci.txt
@@ -17,10 +17,12 @@ HCI
 HCI registers as an nfc device with NFC Core. Requests coming from userspace are
 routed through netlink sockets to NFC Core and then to HCI. From this point,
 they are translated in a sequence of HCI commands sent to the HCI layer in the
-host controller (the chip). The sending context blocks while waiting for the
+host controller (the chip). Commands can be executed synchronously (the sending
-response to arrive.
+context blocks waiting for response) or asynchronously (the response is returned
+from HCI Rx context).
 HCI events can also be received from the host controller. They will be handled
-and a translation will be forwarded to NFC Core as needed.
+and a translation will be forwarded to NFC Core as needed. There are hooks to
+let the HCI driver handle proprietary events or override standard behavior.
 HCI uses 2 execution contexts:
 - one for executing commands : nfc_hci_msg_tx_work(). Only one command
 can be executing at any given moment.
@@ -33,6 +35,8 @@ The Session initialization is an HCI standard which must unfortunately
 support proprietary gates. This is the reason why the driver will pass a list
 of proprietary gates that must be part of the session. HCI will ensure all
 those gates have pipes connected when the hci device is set up.
+In case the chip supports pre-opened gates and pseudo-static pipes, the driver
+can pass that information to HCI core.
 HCI Gates and Pipes
 -------------------
@@ -46,6 +50,13 @@ without knowing the pipe connected to it.
 Driver interface
 ----------------
+A driver is generally written in two parts : the physical link management and
+the HCI management. This makes it easier to maintain a driver for a chip that
+can be connected using various phy (i2c, spi, ...)
+HCI Management
+--------------
 A driver would normally register itself with HCI and provide the following
 entry points:
@@ -53,58 +64,113 @@ struct nfc_hci_ops {
        int (*open)(struct nfc_hci_dev *hdev);
        void (*close)(struct nfc_hci_dev *hdev);
        int (*hci_ready) (struct nfc_hci_dev *hdev);
-        int (*xmit)(struct nfc_hci_dev *hdev, struct sk_buff *skb);
+        int (*xmit) (struct nfc_hci_dev *hdev, struct sk_buff *skb);
-        int (*start_poll)(struct nfc_hci_dev *hdev, u32 protocols);
+        int (*start_poll) (struct nfc_hci_dev *hdev,
-        int (*target_from_gate)(struct nfc_hci_dev *hdev, u8 gate,
+                           u32 im_protocols, u32 tm_protocols);
-                                struct nfc_target *target);
+        int (*dep_link_up)(struct nfc_hci_dev *hdev, struct nfc_target *target,
+                           u8 comm_mode, u8 *gb, size_t gb_len);
+        int (*dep_link_down)(struct nfc_hci_dev *hdev);
+        int (*target_from_gate) (struct nfc_hci_dev *hdev, u8 gate,
+                                 struct nfc_target *target);
        int (*complete_target_discovered) (struct nfc_hci_dev *hdev, u8 gate,
                                           struct nfc_target *target);
-        int (*data_exchange) (struct nfc_hci_dev *hdev,
+        int (*im_transceive) (struct nfc_hci_dev *hdev,
-                              struct nfc_target *target,
+                              struct nfc_target *target, struct sk_buff *skb,
-                              struct sk_buff *skb, struct sk_buff **res_skb);
+                              data_exchange_cb_t cb, void *cb_context);
+        int (*tm_send)(struct nfc_hci_dev *hdev, struct sk_buff *skb);
        int (*check_presence)(struct nfc_hci_dev *hdev,
                              struct nfc_target *target);
+        int (*event_received)(struct nfc_hci_dev *hdev, u8 gate, u8 event,
+                              struct sk_buff *skb);
 };
 - open() and close() shall turn the hardware on and off.
 - hci_ready() is an optional entry point that is called right after the hci
 session has been set up. The driver can use it to do additional initialization
 that must be performed using HCI commands.
- xmit() shall simply write a frame to the chip.
+- xmit() shall simply write a frame to the physical link.
 - start_poll() is an optional entrypoint that shall set the hardware in polling
 mode. This must be implemented only if the hardware uses proprietary gates or a
 mechanism slightly different from the HCI standard.
+- dep_link_up() is called after a p2p target has been detected, to finish
+the p2p connection setup with hardware parameters that need to be passed back
+to nfc core.
+- dep_link_down() is called to bring the p2p link down.
 - target_from_gate() is an optional entrypoint to return the nfc protocols
 corresponding to a proprietary gate.
 - complete_target_discovered() is an optional entry point to let the driver
 perform additional proprietary processing necessary to auto activate the
 discovered target.
- data_exchange() must be implemented by the driver if proprietary HCI commands
+- im_transceive() must be implemented by the driver if proprietary HCI commands
 are required to send data to the tag. Some tag types will require custom
 commands, others can be written to using the standard HCI commands. The driver
 can check the tag type and either do proprietary processing, or return 1 to ask
-for standard processing.
+for standard processing. The data exchange command itself must be sent
+asynchronously.
+- tm_send() is called to send data in the case of a p2p connection
 - check_presence() is an optional entry point that will be called regularly
 by the core to check that an activated tag is still in the field. If this is
 not implemented, the core will not be able to push tag_lost events to the user
 space
+- event_received() is called to handle an event coming from the chip. Driver
+can handle the event or return 1 to let HCI attempt standard processing.
 On the rx path, the driver is responsible to push incoming HCP frames to HCI
 using nfc_hci_recv_frame(). HCI will take care of re-aggregation and handling
 This must be done from a context that can sleep.
-SHDLC
+PHY Management
-----
+--------------
+The physical link (i2c, ...) management is defined by the following struture:
+struct nfc_phy_ops {
+        int (*write)(void *dev_id, struct sk_buff *skb);
+        int (*enable)(void *dev_id);
+        void (*disable)(void *dev_id);
+};
+enable(): turn the phy on (power on), make it ready to transfer data
+disable(): turn the phy off
+write(): Send a data frame to the chip. Note that to enable higher
+layers such as an llc to store the frame for re-emission, this function must
+not alter the skb. It must also not return a positive result (return 0 for
+success, negative for failure).
+Data coming from the chip shall be sent directly to nfc_hci_recv_frame().
+LLC
+---
+Communication between the CPU and the chip often requires some link layer
+protocol. Those are isolated as modules managed by the HCI layer. There are
+currently two modules : nop (raw transfert) and shdlc.
+A new llc must implement the following functions:
+struct nfc_llc_ops {
+        void *(*init) (struct nfc_hci_dev *hdev, xmit_to_drv_t xmit_to_drv,
+                       rcv_to_hci_t rcv_to_hci, int tx_headroom,
+                       int tx_tailroom, int *rx_headroom, int *rx_tailroom,
+                       llc_failure_t llc_failure);
+        void (*deinit) (struct nfc_llc *llc);
+        int (*start) (struct nfc_llc *llc);
+        int (*stop) (struct nfc_llc *llc);
+        void (*rcv_from_drv) (struct nfc_llc *llc, struct sk_buff *skb);
+        int (*xmit_from_hci) (struct nfc_llc *llc, struct sk_buff *skb);
+};
+- init() : allocate and init your private storage
+- deinit() : cleanup
+- start() : establish the logical connection
+- stop () : terminate the logical connection
+- rcv_from_drv() : handle data coming from the chip, going to HCI
+- xmit_from_hci() : handle data sent by HCI, going to the chip
-Most chips use shdlc to ensure integrity and delivery ordering of the HCP
+The llc must be registered with nfc before it can be used. Do that by
-frames between the host controller (the chip) and hosts (entities connected
+calling nfc_llc_register(const char *name, struct nfc_llc_ops *ops);
-to the chip, like the cpu). In order to simplify writing the driver, an shdlc
-layer is available for use by the driver.
+Again, note that the llc does not handle the physical link. It is thus very
-When used, the driver actually registers with shdlc, and shdlc will register
+easy to mix any physical link with any llc for a given chip driver.
-with HCI. HCI sees shdlc as the driver and thus send its HCP frames
-through shdlc->xmit.
-SHDLC adds a new execution context (nfc_shdlc_sm_work()) to run its state
-machine and handle both its rx and tx path.
 Included Drivers
 ----------------
@@ -117,10 +183,12 @@ Execution Contexts
 The execution contexts are the following:
 - IRQ handler (IRQH):
-fast, cannot sleep. stores incoming frames into an shdlc rx queue
+fast, cannot sleep. sends incoming frames to HCI where they are passed to
+the current llc. In case of shdlc, the frame is queued in shdlc rx queue.
 - SHDLC State Machine worker (SMW)
-handles shdlc rx & tx queues. Dispatches HCI cmd responses.
+Only when llc_shdlc is used: handles shdlc rx & tx queues.
+Dispatches HCI cmd responses.
 - HCI Tx Cmd worker (MSGTXWQ)
 Serializes execution of HCI commands. Completes execution in case of response
@@ -166,6 +234,15 @@ waiting command execution. Response processing involves invoking the completion
 callback that was provided by nfc_hci_msg_tx_work() when it sent the command.
 The completion callback will then wake the syscall context.
+It is also possible to execute the command asynchronously using this API:
+static int nfc_hci_execute_cmd_async(struct nfc_hci_dev *hdev, u8 pipe, u8 cmd,
+                               const u8 *param, size_t param_len,
+                               data_exchange_cb_t cb, void *cb_context)
+The workflow is the same, except that the API call returns immediately, and
+the callback will be called with the result from the SMW context.
 Workflow receiving an HCI event or command
 ------------------------------------------
diff --git a/Documentation/nfc/nfc-pn544.txt b/Documentation/nfc/nfc-pn544.txt
index 2fcac9f5996e..b36ca14ca2d6 100644
--- a/Documentation/nfc/nfc-pn544.txt
+++ b/Documentation/nfc/nfc-pn544.txt
@@ -1,32 +1,15 @@
 Kernel driver for the NXP Semiconductors PN544 Near Field
 Communication chip
-Author: Jari Vanhala
-Contact: Matti Aaltonen (matti.j.aaltonen at nokia.com)
 General
 -------
 The PN544 is an integrated transmission module for contactless
 communication. The driver goes under drives/nfc/ and is compiled as a
-module named "pn544". It registers a misc device and creates a device
+module named "pn544".
-file named "/dev/pn544".
 Host Interfaces: I2C, SPI and HSU, this driver supports currently only I2C.
-The Interface
-------------
-The driver offers a sysfs interface for a hardware test and an IOCTL
-interface for selecting between two operating modes. There are read,
-write and poll functions for transferring messages. The two operating
-modes are the normal (HCI) mode and the firmware update mode.
-PN544 is controlled by sending messages from the userspace to the
-chip. The main function of the driver is just to pass those messages
-without caring about the message content.
 Protocols
 ---------
@@ -47,68 +30,3 @@ and third (LSB) bytes of the message. The maximum FW message length is
 For the ETSI HCI specification see
 http://www.etsi.org/WebSite/Technologies/ProtocolSpecification.aspx
-The Hardware Test
-----------------
-The idea of the test is that it can performed by reading from the
-corresponding sysfs file. The test is implemented in the board file
-and it should test that PN544 can be put into the firmware update
-mode. If the test is not implemented the sysfs file does not get
-created.
-Example:
-> cat /sys/module/pn544/drivers/i2c\:pn544/3-002b/nfc_test
-1
-Normal Operation
----------------
-PN544 is powered up when the device file is opened, otherwise it's
-turned off. Only one instance can use the device at a time.
-Userspace applications control PN544 with HCI messages. The hardware
-sends an interrupt when data is available for reading. Data is
-physically read when the read function is called by a userspace
-application. Poll() checks the read interrupt state. Configuration and
-self testing are also done from the userspace using read and write.
-Example platform data:
-static int rx71_pn544_nfc_request_resources(struct i2c_client *client)
-{
-        /* Get and setup the HW resources for the device */
-}
-static void rx71_pn544_nfc_free_resources(void)
-{
-        /* Release the HW resources */
-}
-static void rx71_pn544_nfc_enable(int fw)
-{
-        /* Turn the device on */
-}
-static int rx71_pn544_nfc_test(void)
-{
-        /*
-         * Put the device into the FW update mode
-         * and then back to the normal mode.
-         * Check the behavior and return one on success,
-         * zero on failure.
-         */
-}
-static void rx71_pn544_nfc_disable(void)
-{
-        /* turn the power off */
-}
-static struct pn544_nfc_platform_data rx71_nfc_data = {
-        .request_resources = rx71_pn544_nfc_request_resources,
-        .free_resources = rx71_pn544_nfc_free_resources,
-        .enable = rx71_pn544_nfc_enable,
-        .test = rx71_pn544_nfc_test,
-        .disable = rx71_pn544_nfc_disable,
-};
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index da40efbef6ec..a2b57e0a1db0 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -972,6 +972,18 @@ pinmux core.
 Pin control requests from drivers
 =================================
+When a device driver is about to probe the device core will automatically
+attempt to issue pinctrl_get_select_default() on these devices.
+This way driver writers do not need to add any of the boilerplate code
+of the type found below. However when doing fine-grained state selection
+and not using the "default" state, you may have to do some device driver
+handling of the pinctrl handles and states.
+So if you just want to put the pins for a certain device into the default
+state and be done with it, there is nothing you need to do besides
+providing the proper mapping table. The device core will take care of
+the rest.
 Generally it is discouraged to let individual drivers get and enable pin
 control. So if possible, handle the pin control in platform code or some other
 place where you have access to all the affected struct device * pointers. In
@@ -1097,9 +1109,9 @@ situations that can be electrically unpleasant, you will certainly want to
 mux in and bias pins in a certain way before the GPIO subsystems starts to
 deal with them.
-The above can be hidden: using pinctrl hogs, the pin control driver may be
+The above can be hidden: using the device core, the pinctrl core may be
-setting up the config and muxing for the pins when it is probing,
+setting up the config and muxing for the pins right before the device is
-nevertheless orthogonal to the GPIO subsystem.
+probing, nevertheless orthogonal to the GPIO subsystem.
 But there are also situations where it makes sense for the GPIO subsystem
 to communicate directly with with the pinctrl subsystem, using the latter
diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt
index 6ec291ea1c78..85894d83b352 100644
--- a/Documentation/power/freezing-of-tasks.txt
+++ b/Documentation/power/freezing-of-tasks.txt
@@ -223,3 +223,8 @@ since they ask the freezer to skip freezing this task, since it is anyway
 only after the entire suspend/hibernation sequence is complete.
 So, to summarize, use [un]lock_system_sleep() instead of directly using
 mutex_[un]lock(&pm_mutex). That would prevent freezing failures.
+V. Miscellaneous
+/sys/power/pm_freeze_timeout controls how long it will cost at most to freeze
+all user space processes or all freezable kernel threads, in unit of millisecond.
+The default value is 20000, with range of unsigned integer.
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 03591a750f99..6c9f5d9aa115 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -426,6 +426,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
      'power.runtime_error' is set or 'power.disable_depth' is greater than
      zero)
+  bool pm_runtime_active(struct device *dev);
+    - return true if the device's runtime PM status is 'active' or its
+      'power.disable_depth' field is not equal to zero, or false otherwise
  bool pm_runtime_suspended(struct device *dev);
    - return true if the device's runtime PM status is 'suspended' and its
      'power.disable_depth' field is equal to zero, or false otherwise
diff --git a/Documentation/powerpc/cpu_features.txt b/Documentation/powerpc/cpu_features.txt
index ffa4183fdb8b..ae09df8722c8 100644
--- a/Documentation/powerpc/cpu_features.txt
+++ b/Documentation/powerpc/cpu_features.txt
@@ -11,10 +11,10 @@ split instruction and data caches, and if the CPU supports the DOZE and NAP
 sleep modes.
 Detection of the feature set is simple. A list of processors can be found in
-arch/ppc/kernel/cputable.c. The PVR register is masked and compared with each
+arch/powerpc/kernel/cputable.c. The PVR register is masked and compared with
-value in the list. If a match is found, the cpu_features of cur_cpu_spec is
+each value in the list. If a match is found, the cpu_features of cur_cpu_spec
-assigned to the feature bitmask for this processor and a __setup_cpu function
+is assigned to the feature bitmask for this processor and a __setup_cpu
-is called.
+function is called.
 C code may test 'cur_cpu_spec[smp_processor_id()]->cpu_features' for a
 particular feature bit. This is done in quite a few places, for example
@@ -51,6 +51,6 @@ should be used in the majority of cases.
 The END_FTR_SECTION macros are implemented by storing information about this
 code in the '__ftr_fixup' ELF section. When do_cpu_ftr_fixups
-(arch/ppc/kernel/misc.S) is invoked, it will iterate over the records in
+(arch/powerpc/kernel/misc.S) is invoked, it will iterate over the records in
 __ftr_fixup, and if the required feature is not present it will loop writing
 nop's from each BEGIN_FTR_SECTION to END_FTR_SECTION.
diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.txt
new file mode 100644
index 000000000000..c907be41d60f
--- /dev/null
+++ b/Documentation/powerpc/transactional_memory.txt
@@ -0,0 +1,175 @@
+Transactional Memory support
+============================
+POWER kernel support for this feature is currently limited to supporting
+its use by user programs.  It is not currently used by the kernel itself.
+This file aims to sum up how it is supported by Linux and what behaviour you
+can expect from your user programs.
+Basic overview
+==============
+Hardware Transactional Memory is supported on POWER8 processors, and is a
+feature that enables a different form of atomic memory access.  Several new
+instructions are presented to delimit transactions; transactions are
+guaranteed to either complete atomically or roll back and undo any partial
+changes.
+A simple transaction looks like this:
+begin_move_money:
+  tbegin
+  beq   abort_handler
+  ld    r4, SAVINGS_ACCT(r3)
+  ld    r5, CURRENT_ACCT(r3)
+  subi  r5, r5, 1
+  addi  r4, r4, 1
+  std   r4, SAVINGS_ACCT(r3)
+  std   r5, CURRENT_ACCT(r3)
+  tend
+  b     continue
+abort_handler:
+  ... test for odd failures ...
+  /* Retry the transaction if it failed because it conflicted with
+   * someone else: */
+  b     begin_move_money
+The 'tbegin' instruction denotes the start point, and 'tend' the end point.
+Between these points the processor is in 'Transactional' state; any memory
+references will complete in one go if there are no conflicts with other
+transactional or non-transactional accesses within the system.  In this
+example, the transaction completes as though it were normal straight-line code
+IF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an
+atomic move of money from the current account to the savings account has been
+performed.  Even though the normal ld/std instructions are used (note no
+lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
+updated, or neither will be updated.
+If, in the meantime, there is a conflict with the locations accessed by the
+transaction, the transaction will be aborted by the CPU.  Register and memory
+state will roll back to that at the 'tbegin', and control will continue from
+'tbegin+4'.  The branch to abort_handler will be taken this second time; the
+abort handler can check the cause of the failure, and retry.
+Checkpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR
+and a few other status/flag regs; see the ISA for details.
+Causes of transaction aborts
+============================
+- Conflicts with cache lines used by other processors
+- Signals
+- Context switches
+- See the ISA for full documentation of everything that will abort transactions.
+Syscalls
+========
+Performing syscalls from within transaction is not recommended, and can lead
+to unpredictable results.
+Syscalls do not by design abort transactions, but beware: The kernel code will
+not be running in transactional state.  The effect of syscalls will always
+remain visible, but depending on the call they may abort your transaction as a
+side-effect, read soon-to-be-aborted transactional data that should not remain
+invisible, etc.  If you constantly retry a transaction that constantly aborts
+itself by calling a syscall, you'll have a livelock & make no progress.
+Simple syscalls (e.g. sigprocmask()) "could" be OK.  Even things like write()
+from, say, printf() should be OK as long as the kernel does not access any
+memory that was accessed transactionally.
+Consider any syscalls that happen to work as debug-only -- not recommended for
+production use.  Best to queue them up till after the transaction is over.
+Signals
+=======
+Delivery of signals (both sync and async) during transactions provides a second
+thread state (ucontext/mcontext) to represent the second transactional register
+state.  Signal delivery 'treclaim's to capture both register states, so signals
+abort transactions.  The usual ucontext_t passed to the signal handler
+represents the checkpointed/original register state; the signal appears to have
+arisen at 'tbegin+4'.
+If the sighandler ucontext has uc_link set, a second ucontext has been
+delivered.  For future compatibility the MSR.TS field should be checked to
+determine the transactional state -- if so, the second ucontext in uc->uc_link
+represents the active transactional registers at the point of the signal.
+For 64-bit processes, uc->uc_mcontext.regs->msr is a full 64-bit MSR and its TS
+field shows the transactional mode.
+For 32-bit processes, the mcontext's MSR register is only 32 bits; the top 32
+bits are stored in the MSR of the second ucontext, i.e. in
+uc->uc_link->uc_mcontext.regs->msr.  The top word contains the transactional
+state TS.
+However, basic signal handlers don't need to be aware of transactions
+and simply returning from the handler will deal with things correctly:
+Transaction-aware signal handlers can read the transactional register state
+from the second ucontext.  This will be necessary for crash handlers to
+determine, for example, the address of the instruction causing the SIGSEGV.
+Example signal handler:
+    void crash_handler(int sig, siginfo_t *si, void *uc)
+    {
+      ucontext_t *ucp = uc;
+      ucontext_t *transactional_ucp = ucp->uc_link;
+      if (ucp_link) {
+        u64 msr = ucp->uc_mcontext.regs->msr;
+        /* May have transactional ucontext! */
+#ifndef __powerpc64__
+        msr |= ((u64)transactional_ucp->uc_mcontext.regs->msr) << 32;
+#endif
+        if (MSR_TM_ACTIVE(msr)) {
+           /* Yes, we crashed during a transaction.  Oops. */
+   fprintf(stderr, "Transaction to be restarted at 0x%llx, but "
+                           "crashy instruction was at 0x%llx\n",
+                           ucp->uc_mcontext.regs->nip,
+                           transactional_ucp->uc_mcontext.regs->nip);
+        }
+      }
+      fix_the_problem(ucp->dar);
+    }
+Failure cause codes used by kernel
+==================================
+These are defined in <asm/reg.h>, and distinguish different reasons why the
+kernel aborted a transaction:
+ TM_CAUSE_RESCHED       Thread was rescheduled.
+ TM_CAUSE_FAC_UNAV      FP/VEC/VSX unavailable trap.
+ TM_CAUSE_SYSCALL       Currently unused; future syscalls that must abort
+                        transactions for consistency will use this.
+ TM_CAUSE_SIGNAL        Signal delivered.
+ TM_CAUSE_MISC          Currently unused.
+These can be checked by the user program's abort handler as TEXASR[0:7].
+GDB
+===
+GDB and ptrace are not currently TM-aware.  If one stops during a transaction,
+it looks like the transaction has just started (the checkpointed state is
+presented).  The transaction cannot then be continued and will take the failure
+handler route.  Furthermore, the transactional 2nd register state will be
+inaccessible.  GDB can currently be used on programs using TM, but not sensibly
+in parts within transactions.
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 8ffb274367c7..e8a6aa473bab 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -53,6 +53,14 @@ Struct Resources:
        For printing struct resources. The 'R' and 'r' specifiers result in a
        printed resource with ('R') or without ('r') a decoded flags member.
+Physical addresses:
+        %pa     0x01234567 or 0x0123456789abcdef
+        For printing a phys_addr_t type (and its derivatives, such as
+        resource_size_t) which can vary based on build options, regardless of
+        the width of the CPU data path. Passed by reference.
 Raw buffer as a hex string:
        %*ph    00 01 02  ...  3f
        %*phC   00:01:02: ... :3f
@@ -150,9 +158,9 @@ s64 SHOULD be printed with %lld/%llx, (long long):
        printk("%lld", (long long)s64_var);
 If <type> is dependent on a config option for its size (e.g., sector_t,
-blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent
+blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a
-for its size (e.g., tcflag_t), use a format specifier of its largest
+format specifier of its largest possible type and explicitly cast to it.
-possible type and explicitly cast to it.  Example:
+Example:
        printk("test: sector number/total blocks: %llu/%llu\n",
                (unsigned long long)sector, (unsigned long long)blockcount);
diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 0a25a9191864..067c47d46917 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -133,6 +133,16 @@ hardware.
        Interrupts: locally disabled.
        This call must not sleep
+  send_xchar(port,ch)
+        Transmit a high priority character, even if the port is stopped.
+        This is used to implement XON/XOFF flow control and tcflow().  If
+        the serial driver does not implement this function, the tty core
+        will append the character to the circular buffer and then call
+        start_tx() / stop_tx() to flush the data out.
+        Locking: none.
+        Interrupts: caller dependent.
  stop_rx(port)
        Stop receiving characters; the port is in the process of
        being closed.
@@ -242,9 +252,8 @@ hardware.
  pm(port,state,oldstate)
        Perform any power management related activities on the specified
-        port.  State indicates the new state (defined by ACPI D0-D3),
+        port.  State indicates the new state (defined by
-        oldstate indicates the previous state.  Essentially, D0 means
+        enum uart_pm_state), oldstate indicates the previous state.
-        fully on, D3 means powered down.
        This function should not be used to grab any resources.
@@ -255,6 +264,10 @@ hardware.
        Locking: none.
        Interrupts: caller dependent.
+  set_wake(port,state)
+        Enable/disable power management wakeup on serial activity.  Not
+        currently implemented.
  type(port)
        Return a pointer to a string constant describing the specified
        port, or return NULL, in which case the string 'unknown' is
@@ -307,6 +320,31 @@ hardware.
        Locking: none.
        Interrupts: caller dependent.
+  poll_init(port)
+        Called by kgdb to perform the minimal hardware initialization needed
+        to support poll_put_char() and poll_get_char().  Unlike ->startup()
+        this should not request interrupts.
+        Locking: tty_mutex and tty_port->mutex taken.
+        Interrupts: n/a.
+  poll_put_char(port,ch)
+        Called by kgdb to write a single character directly to the serial
+        port.  It can and should block until there is space in the TX FIFO.
+        Locking: none.
+        Interrupts: caller dependent.
+        This call must not sleep
+  poll_get_char(port)
+        Called by kgdb to read a single character directly from the serial
+        port.  If data is available, it should be returned; otherwise
+        the function should return NO_POLL_CHAR immediately.
+        Locking: none.
+        Interrupts: caller dependent.
+        This call must not sleep
 Other functions
 ---------------
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index b9cfd339a6fa..ce6581c8ca26 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -890,8 +890,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
    enable_msi  - Enable Message Signaled Interrupt (MSI) (default = off)
    power_save  - Automatic power-saving timeout (in second, 0 =
                disable)
-    power_save_controller - Reset HD-audio controller in power-saving mode
+    power_save_controller - Support runtime D3 of HD-audio controller
-                (default = on)
+                (-1 = on for supported chip (default), false = off,
+                 true = force to on even for unsupported hardware)
    align_buffer_size - Force rounding of buffer/period sizes to multiples
                      of 128 bytes. This is more efficient in terms of memory
                      access but isn't required by the HDA spec and prevents
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt
index 16dfe57f1731..bb8b0dc532b8 100644
--- a/Documentation/sound/alsa/HD-Audio-Models.txt
+++ b/Documentation/sound/alsa/HD-Audio-Models.txt
@@ -53,7 +53,7 @@ ALC882/883/885/888/889
  acer-aspire-8930g     Acer Aspire 8330G/6935G
  acer-aspire           Acer Aspire others
  inv-dmic      Inverted internal mic workaround
-  no-primary-hp         VAIO Z workaround (for fixed speaker DAC)
+  no-primary-hp         VAIO Z/VGC-LN51JGB workaround (for fixed speaker DAC)
 ALC861/660
 ==========
diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt
index 7813c06a5c71..d4faa63ff352 100644
--- a/Documentation/sound/alsa/HD-Audio.txt
+++ b/Documentation/sound/alsa/HD-Audio.txt
@@ -176,14 +176,14 @@ support the automatic probing (yet as of 2.6.28).  And, BIOS is often,
 yes, pretty often broken.  It sets up wrong values and screws up the
 driver.
-The preset model is provided basically to overcome such a situation.
+The preset model (or recently called as "fix-up") is provided
-When the matching preset model is found in the white-list, the driver
+basically to overcome such a situation.  When the matching preset
-assumes the static configuration of that preset and builds the mixer
+model is found in the white-list, the driver assumes the static
-elements and PCM streams based on the static information.  Thus, if
+configuration of that preset with the correct pin setup, etc.
-you have a newer machine with a slightly different PCI SSID from the
+Thus, if you have a newer machine with a slightly different PCI SSID
-existing one, you may have a good chance to re-use the same model.
+(or codec SSID) from the existing one, you may have a good chance to
-You can pass the `model` option to specify the preset model instead of
+re-use the same model.  You can pass the `model` option to specify the
-PCI SSID look-up.
+preset model instead of PCI (and codec-) SSID look-up.
 What `model` option values are available depends on the codec chip.
 Check your codec chip from the codec proc file (see "Codec Proc-File"
@@ -199,17 +199,12 @@ non-working HD-audio hardware is to check HD-audio codec and several
 different `model` option values.  If you have any luck, some of them
 might suit with your device well.
-Some codecs such as ALC880 have a special model option `model=test`.
+There are a few special model option values:
-This configures the driver to provide as many mixer controls as
+- when 'nofixup' is passed, the device-specific fixups in the codec
-possible for every single pin feature except for the unsolicited
+  parser are skipped.
-events (and maybe some other specials).  Adjust each mixer element and
+- when `generic` is passed, the codec-specific parser is skipped and
-try the I/O in the way of trial-and-error until figuring out the whole
+  only the generic parser is used.
-I/O pin mappings.
-Note that `model=generic` has a special meaning.  It means to use the
-generic parser regardless of the codec.  Usually the codec-specific
-parser is much better than the generic parser (as now).  Thus this
-option is more about the debugging purpose.
 Speaker and Headphone Output
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -387,9 +382,8 @@ init_verbs::
  (separated with a space).
 hints::
  Shows / stores hint strings for codec parsers for any use.
-  Its format is `key = value`.  For example, passing `hp_detect = yes`
+  Its format is `key = value`.  For example, passing `jack_detect = no`
-  to IDT/STAC codec parser will result in the disablement of the
+  will disable the jack detection of the machine completely.
-  headphone detection.
 init_pin_configs::
  Shows the initial pin default config values set by BIOS.
 driver_pin_configs::
@@ -421,6 +415,61 @@ re-configure based on that state, run like below:
 ------------------------------------------------------------------------
+Hint Strings
+~~~~~~~~~~~~
+The codec parser have several switches and adjustment knobs for
+matching better with the actual codec or device behavior.  Many of
+them can be adjusted dynamically via "hints" strings as mentioned in
+the section above.  For example, by passing `jack_detect = no` string
+via sysfs or a patch file, you can disable the jack detection, thus
+the codec parser will skip the features like auto-mute or mic
+auto-switch.  As a boolean value, either `yes`, `no`, `true`, `false`,
+`1` or `0` can be passed.
+The generic parser supports the following hints:
+- jack_detect (bool): specify whether the jack detection is available
+  at all on this machine; default true
+- inv_jack_detect (bool): indicates that the jack detection logic is
+  inverted
+- trigger_sense (bool): indicates that the jack detection needs the
+  explicit call of AC_VERB_SET_PIN_SENSE verb
+- inv_eapd (bool): indicates that the EAPD is implemented in the
+  inverted logic
+- pcm_format_first (bool): sets the PCM format before the stream tag
+  and channel ID
+- sticky_stream (bool): keep the PCM format, stream tag and ID as long
+  as possible; default true
+- spdif_status_reset (bool): reset the SPDIF status bits at each time
+  the SPDIF stream is set up
+-  pin_amp_workaround (bool): the output pin may have multiple amp
+  values
+- single_adc_amp (bool): ADCs can have only single input amps
+- auto_mute (bool): enable/disable the headphone auto-mute feature;
+  default true
+- auto_mic (bool): enable/disable the mic auto-switch feature; default
+  true
+- line_in_auto_switch (bool): enable/disable the line-in auto-switch
+  feature; default false
+- need_dac_fix (bool): limits the DACs depending on the channel count
+- primary_hp (bool): probe headphone jacks as the primary outputs;
+  default true
+- multi_cap_vol (bool): provide multiple capture volumes
+- inv_dmic_split (bool): provide split internal mic volume/switch for
+  phase-inverted digital mics
+- indep_hp (bool): provide the independent headphone PCM stream and
+  the corresponding mixer control, if available
+- add_stereo_mix_input (bool): add the stereo mix (analog-loopback
+  mix) to the input mux if available
+- add_out_jack_modes (bool): add "xxx Jack Mode" enum controls to each
+  output jack for allowing to change the headphone amp capability
+- add_in_jack_modes (bool): add "xxx Jack Mode" enum controls to each
+  input jack for allowing to change the mic bias vref
+- power_down_unused (bool): power down the unused widgets
+- mixer_nid (int): specifies the widget NID of the analog-loopback
+  mixer
 Early Patching
 ~~~~~~~~~~~~~~
 When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a
@@ -445,7 +494,7 @@ A patch file is a plain text file which looks like below:
  0x20 0x400 0xff
  [hint]
-  hp_detect = yes
+  jack_detect = no
 ------------------------------------------------------------------------
 The file needs to have a line `[codec]`.  The next line should contain
@@ -531,6 +580,13 @@ cable is unplugged.  Thus, if you hear noises, suspect first the
 power-saving.  See /sys/module/snd_hda_intel/parameters/power_save to
 check the current value.  If it's non-zero, the feature is turned on.
+The recent kernel supports the runtime PM for the HD-audio controller
+chip, too.  It means that the HD-audio controller is also powered up /
+down dynamically.  The feature is enabled only for certain controller
+chips like Intel LynxPoint.  You can enable/disable this feature
+forcibly by setting `power_save_controller` option, which is also
+available at /sys/module/snd_hda_intel/parameters directory.
 Tracepoints
 ~~~~~~~~~~~
@@ -587,8 +643,9 @@ The latest development codes for HD-audio are found on sound git tree:
 - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
 The master branch or for-next branches can be used as the main
-development branches in general while the HD-audio specific patches
+development branches in general while the development for the current
-are committed in topic/hda branch.
+and next kernels are found in for-linus and for-next branches,
+respectively.
 If you are using the latest Linus tree, it'd be better to pull the
 above GIT tree onto it.  If you are using the older kernels, an easy
@@ -699,7 +756,11 @@ won't be always updated.  For example, the volume values are usually
 cached in the driver, and thus changing the widget amp value directly
 via hda-verb won't change the mixer value.
-The hda-verb program is found in the ftp directory:
+The hda-verb program is included now in alsa-tools:
+- git://git.alsa-project.org/alsa-tools.git
+Also, the old stand-alone package is found in the ftp directory:
 - ftp://ftp.suse.com/pub/people/tiwai/misc/
@@ -777,3 +838,18 @@ A git repository is available:
 See README file in the tarball for more details about hda-emu
 program.
+hda-jack-retask
+~~~~~~~~~~~~~~~
+hda-jack-retask is a user-friendly GUI program to manipulate the
+HD-audio pin control for jack retasking.  If you have a problem about
+the jack assignment, try this program and check whether you can get
+useful results.  Once when you figure out the proper pin assignment,
+it can be fixed either in the driver code statically or via passing a
+firmware patch file (see "Early Patching" section).
+The program is included in alsa-tools now:
+- git://git.alsa-project.org/alsa-tools.git
diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt
index 90e9b3a11abc..0bcc55155911 100644
--- a/Documentation/sound/alsa/compress_offload.txt
+++ b/Documentation/sound/alsa/compress_offload.txt
@@ -145,6 +145,52 @@ Modifications include:
 - Addition of encoding options when required (derived from OpenMAX IL)
 - Addition of rateControlSupported (missing in OpenMAX AL)
+Gapless Playback
+================
+When playing thru an album, the decoders have the ability to skip the encoder
+delay and padding and directly move from one track content to another. The end
+user can perceive this as gapless playback as we dont have silence while
+switching from one track to another
+Also, there might be low-intensity noises due to encoding. Perfect gapless is
+difficult to reach with all types of compressed data, but works fine with most
+music content. The decoder needs to know the encoder delay and encoder padding.
+So we need to pass this to DSP. This metadata is extracted from ID3/MP4 headers
+and are not present by default in the bitstream, hence the need for a new
+interface to pass this information to the DSP. Also DSP and userspace needs to
+switch from one track to another and start using data for second track.
+The main additions are:
+- set_metadata
+This routine sets the encoder delay and encoder padding. This can be used by
+decoder to strip the silence. This needs to be set before the data in the track
+is written.
+- set_next_track
+This routine tells DSP that metadata and write operation sent after this would
+correspond to subsequent track
+- partial drain
+This is called when end of file is reached. The userspace can inform DSP that
+EOF is reached and now DSP can start skipping padding delay. Also next write
+data would belong to next track
+Sequence flow for gapless would be:
+- Open
+- Get caps / codec caps
+- Set params
+- Set metadata of the first track
+- Fill data of the first track
+- Trigger start
+- User-space finished sending all,
+- Indicaite next track data by sending set_next_track
+- Set metadata of the next track
+- then call partial_drain to flush most of buffer in DSP
+- Fill data of the next track
+- DSP switches to second track
+(note: order for partial_drain and write for next track can be reversed as well)
 Not supported:
 - Support for VoIP/circuit-switched calls is not the target of this
diff --git a/Documentation/thermal/nouveau_thermal b/Documentation/thermal/nouveau_thermal
new file mode 100644
index 000000000000..efceb7828f54
--- /dev/null
+++ b/Documentation/thermal/nouveau_thermal
@@ -0,0 +1,81 @@
+Kernel driver nouveau
+===================
+Supported chips:
+* NV43+
+Authors: Martin Peres (mupuf) <martin.peres@labri.fr>
+Description
+---------
+This driver allows to read the GPU core temperature, drive the GPU fan and
+set temperature alarms.
+Currently, due to the absence of in-kernel API to access HWMON drivers, Nouveau
+cannot access any of the i2c external monitoring chips it may find. If you
+have one of those, temperature and/or fan management through Nouveau's HWMON
+interface is likely not to work. This document may then not cover your situation
+entirely.
+Temperature management
+--------------------
+Temperature is exposed under as a read-only HWMON attribute temp1_input.
+In order to protect the GPU from overheating, Nouveau supports 4 configurable
+temperature thresholds:
+ * Fan_boost: Fan speed is set to 100% when reaching this temperature;
+ * Downclock: The GPU will be downclocked to reduce its power dissipation;
+ * Critical: The GPU is put on hold to further lower power dissipation;
+ * Shutdown: Shut the computer down to protect your GPU.
+WARNING: Some of these thresholds may not be used by Nouveau depending
+on your chipset.
+The default value for these thresholds comes from the GPU's vbios. These
+thresholds can be configured thanks to the following HWMON attributes:
+ * Fan_boost: temp1_auto_point1_temp and temp1_auto_point1_temp_hyst;
+ * Downclock: temp1_max and temp1_max_hyst;
+ * Critical: temp1_crit and temp1_crit_hyst;
+ * Shutdown: temp1_emergency and temp1_emergency_hyst.
+NOTE: Remember that the values are stored as milli degrees Celcius. Don't forget
+to multiply!
+Fan management
+------------
+Not all cards have a drivable fan. If you do, then the following HWMON
+attributes should be available:
+ * pwm1_enable: Current fan management mode (NONE, MANUAL or AUTO);
+ * pwm1: Current PWM value (power percentage);
+ * pwm1_min: The minimum PWM speed allowed;
+ * pwm1_max: The maximum PWM speed allowed (bypassed when hitting Fan_boost);
+You may also have the following attribute:
+ * fan1_input: Speed in RPM of your fan.
+Your fan can be driven in different modes:
+ * 0: The fan is left untouched;
+ * 1: The fan can be driven in manual (use pwm1 to change the speed);
+ * 2; The fan is driven automatically depending on the temperature.
+NOTE: Be sure to use the manual mode if you want to drive the fan speed manually
+NOTE2: Not all fan management modes may be supported on all chipsets. We are
+working on it.
+Bug reports
+---------
+Thermal management on Nouveau is new and may not work on all cards. If you have
+inquiries, please ping mupuf on IRC (#nouveau, freenode).
+Bug reports should be filled on Freedesktop's bug tracker. Please follow
+http://nouveau.freedesktop.org/wiki/Bugs
diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt
index cf794af22855..e1498ff8cf94 100644
--- a/Documentation/trace/events-power.txt
+++ b/Documentation/trace/events-power.txt
@@ -17,7 +17,7 @@ Cf. include/trace/events/power.h for the events definitions.
 1. Power state switch events
 ============================
-1.1 New trace API
+1.1 Trace API
 -----------------
 A 'cpu' event class gathers the CPU-related events: cpuidle and
@@ -41,31 +41,6 @@ The event which has 'state=4294967295' in the trace is very important to the use
 space tools which are using it to detect the end of the current state, and so to
 correctly draw the states diagrams and to calculate accurate statistics etc.
-1.2 DEPRECATED trace API
------------------------
-A new Kconfig option CONFIG_EVENT_POWER_TRACING_DEPRECATED with the default value of
-'y' has been created. This allows the legacy trace power API to be used conjointly
-with the new trace API.
-The Kconfig option, the old trace API (in include/trace/events/power.h) and the
-old trace points will disappear in a future release (namely 2.6.41).
-power_start             "type=%lu state=%lu cpu_id=%lu"
-power_frequency         "type=%lu state=%lu cpu_id=%lu"
-power_end               "cpu_id=%lu"
-The 'type' parameter takes one of those macros:
- . POWER_NONE   = 0,
- . POWER_CSTATE = 1,    /* C-State */
- . POWER_PSTATE = 2,    /* Frequency change or DVFS */
-The 'state' parameter is set depending on the type:
- . Target C-state for type=POWER_CSTATE,
- . Target frequency for type=POWER_PSTATE,
-power_end is used to indicate the exit of a state, corresponding to the latest
-power_start event.
 2. Clocks events
 ================
 The clock events are used for clock enable/disable and for
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index 6f51fed45f2d..53d6a3c51d87 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -1842,6 +1842,89 @@ an error.
 # cat buffer_size_kb
 85
+Snapshot
+--------
+CONFIG_TRACER_SNAPSHOT makes a generic snapshot feature
+available to all non latency tracers. (Latency tracers which
+record max latency, such as "irqsoff" or "wakeup", can't use
+this feature, since those are already using the snapshot
+mechanism internally.)
+Snapshot preserves a current trace buffer at a particular point
+in time without stopping tracing. Ftrace swaps the current
+buffer with a spare buffer, and tracing continues in the new
+current (=previous spare) buffer.
+The following debugfs files in "tracing" are related to this
+feature:
+  snapshot:
+        This is used to take a snapshot and to read the output
+        of the snapshot. Echo 1 into this file to allocate a
+        spare buffer and to take a snapshot (swap), then read
+        the snapshot from this file in the same format as
+        "trace" (described above in the section "The File
+        System"). Both reads snapshot and tracing are executable
+        in parallel. When the spare buffer is allocated, echoing
+        0 frees it, and echoing else (positive) values clear the
+        snapshot contents.
+        More details are shown in the table below.
+        status\input  |     0      |     1      |    else    |
+        --------------+------------+------------+------------+
+        not allocated |(do nothing)| alloc+swap |   EINVAL   |
+        --------------+------------+------------+------------+
+        allocated     |    free    |    swap    |   clear    |
+        --------------+------------+------------+------------+
+Here is an example of using the snapshot feature.
+ # echo 1 > events/sched/enable
+ # echo 1 > snapshot
+ # cat snapshot
+# tracer: nop
+#
+# entries-in-buffer/entries-written: 71/71   #P:8
+#
+#                              _-----=> irqs-off
+#                             / _----=> need-resched
+#                            | / _---=> hardirq/softirq
+#                            || / _--=> preempt-depth
+#                            ||| /     delay
+#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
+#              | |       |   ||||       |         |
+          <idle>-0     [005] d...  2440.603828: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2242 next_prio=120
+           sleep-2242  [005] d...  2440.603846: sched_switch: prev_comm=snapshot-test-2 prev_pid=2242 prev_prio=120 prev_state=R ==> next_comm=kworker/5:1 next_pid=60 next_prio=120
+[...]
+          <idle>-0     [002] d...  2440.707230: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2229 next_prio=120
+ # cat trace
+# tracer: nop
+#
+# entries-in-buffer/entries-written: 77/77   #P:8
+#
+#                              _-----=> irqs-off
+#                             / _----=> need-resched
+#                            | / _---=> hardirq/softirq
+#                            || / _--=> preempt-depth
+#                            ||| /     delay
+#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
+#              | |       |   ||||       |         |
+          <idle>-0     [007] d...  2440.707395: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2243 next_prio=120
+ snapshot-test-2-2229  [002] d...  2440.707438: sched_switch: prev_comm=snapshot-test-2 prev_pid=2229 prev_prio=120 prev_state=S ==> next_comm=swapper/2 next_pid=0 next_prio=120
+[...]
+If you try to use this snapshot feature when current tracer is
+one of the latency tracers, you will get the following results.
+ # echo wakeup > current_tracer
+ # echo 1 > snapshot
+bash: echo: write error: Device or resource busy
+ # cat snapshot
+cat: snapshot: Device or resource busy
 -----------
 More details can be found in the source code, in the
diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828
index a8a65753e544..55a21deab7db 100644
--- a/Documentation/video4linux/CARDLIST.au0828
+++ b/Documentation/video4linux/CARDLIST.au0828
@@ -1,5 +1,5 @@
  0 -> Unknown board                            (au0828)
-  1 -> Hauppauge HVR950Q                        (au0828)        [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008,2040:7260,2040:7213]
+  1 -> Hauppauge HVR950Q                        (au0828)        [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008,2040:7260,2040:7213,2040:7270]
  2 -> Hauppauge HVR850                         (au0828)        [2040:7240]
  3 -> DViCO FusionHDTV USB                     (au0828)        [0fe9:d620]
  4 -> Hauppauge HVR950Q rev xxF8               (au0828)        [2040:7201,2040:7211,2040:7281]
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885
index 1299b5e82d7f..9f056d512e35 100644
--- a/Documentation/video4linux/CARDLIST.cx23885
+++ b/Documentation/video4linux/CARDLIST.cx23885
@@ -36,3 +36,5 @@
 35 -> TeVii S471                                          [d471:9022]
 36 -> Hauppauge WinTV-HVR1255                             [0070:2259]
 37 -> Prof Revolution DVB-S2 8000                         [8000:3034]
+ 38 -> Hauppauge WinTV-HVR4400                             [0070:c108,0070:c138,0070:c12a,0070:c1f8]
+ 39 -> AVerTV Hybrid Express Slim HC81R                    [1461:d939]
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index d99262dda533..3f12865b2a88 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -76,7 +76,7 @@
 76 -> KWorld PlusTV 340U or UB435-Q (ATSC)     (em2870)        [1b80:a340]
 77 -> EM2874 Leadership ISDBT                  (em2874)
 78 -> PCTV nanoStick T2 290e                   (em28174)
- 79 -> Terratec Cinergy H5                      (em2884)        [0ccd:008e,0ccd:00ac,0ccd:10a2,0ccd:10ad]
+ 79 -> Terratec Cinergy H5                      (em2884)        [0ccd:10a2,0ccd:10ad]
 80 -> PCTV DVB-S2 Stick (460e)                 (em28174)
 81 -> Hauppauge WinTV HVR 930C                 (em2884)        [2040:1605]
 82 -> Terratec Cinergy HTC Stick               (em2884)        [0ccd:00b2]
@@ -84,3 +84,4 @@
 84 -> MaxMedia UB425-TC                        (em2874)        [1b80:e425]
 85 -> PCTV QuatroStick (510e)                  (em2884)        [2304:0242]
 86 -> PCTV QuatroStick nano (520e)             (em2884)        [2013:0251]
+ 87 -> Terratec Cinergy HTC USB XS              (em2884)        [0ccd:008e,0ccd:00ac]
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 94d9025aa82d..b3ad68309109 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -189,3 +189,4 @@
 188 -> Sensoray 811/911                         [6000:0811,6000:0911]
 189 -> Kworld PC150-U                           [17de:a134]
 190 -> Asus My Cinema PS3-100                   [1043:48cd]
+191 -> Hawell HW-9004V1
diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt
deleted file mode 100644
index e0cdae491858..000000000000
--- a/Documentation/video4linux/et61x251.txt
+++ /dev/null
@@ -1,315 +0,0 @@
-                       ET61X[12]51 PC Camera Controllers
-                                Driver for Linux
-                       =================================
-                               - Documentation -
-Index
-=====
-1.  Copyright
-2.  Disclaimer
-3.  License
-4.  Overview and features
-5.  Module dependencies
-6.  Module loading
-7.  Module parameters
-8.  Optional device control through "sysfs"
-9.  Supported devices
-10. Notes for V4L2 application developers
-11. Contact information
-1. Copyright
-============
-Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it>
-2. Disclaimer
-=============
-Etoms is a trademark of Etoms Electronics Corp.
-This software is not developed or sponsored by Etoms Electronics.
-3. License
-==========
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-4. Overview and features
-========================
-This driver supports the video interface of the devices mounting the ET61X151
-or ET61X251 PC Camera Controllers.
-It's worth to note that Etoms Electronics has never collaborated with the
-author during the development of this project; despite several requests,
-Etoms Electronics also refused to release enough detailed specifications of
-the video compression engine.
-The driver relies on the Video4Linux2 and USB core modules. It has been
-designed to run properly on SMP systems as well.
-The latest version of the ET61X[12]51 driver can be found at the following URL:
-http://www.linux-projects.org/
-Some of the features of the driver are:
- full compliance with the Video4Linux2 API (see also "Notes for V4L2
-  application developers" paragraph);
- available mmap or read/poll methods for video streaming through isochronous
-  data transfers;
- automatic detection of image sensor;
- support for any window resolutions and optional panning within the maximum
-  pixel area of image sensor;
- image downscaling with arbitrary scaling factors from 1 and 2 in both
-  directions (see "Notes for V4L2 application developers" paragraph);
- two different video formats for uncompressed or compressed data in low or
-  high compression quality (see also "Notes for V4L2 application developers"
-  paragraph);
- full support for the capabilities of every possible image sensors that can
-  be connected to the ET61X[12]51 bridges, including, for instance, red, green,
-  blue and global gain adjustments and exposure control (see "Supported
-  devices" paragraph for details);
- use of default color settings for sunlight conditions;
- dynamic I/O interface for both ET61X[12]51 and image sensor control (see
-  "Optional device control through 'sysfs'" paragraph);
- dynamic driver control thanks to various module parameters (see "Module
-  parameters" paragraph);
- up to 64 cameras can be handled at the same time; they can be connected and
-  disconnected from the host many times without turning off the computer, if
-  the system supports hotplugging;
- no known bugs.
-5. Module dependencies
-======================
-For it to work properly, the driver needs kernel support for Video4Linux and
-USB.
-The following options of the kernel configuration file must be enabled and
-corresponding modules must be compiled:
-        # Multimedia devices
-        #
-        CONFIG_VIDEO_DEV=m
-To enable advanced debugging functionality on the device through /sysfs:
-        # Multimedia devices
-        #
-        CONFIG_VIDEO_ADV_DEBUG=y
-        # USB support
-        #
-        CONFIG_USB=m
-In addition, depending on the hardware being used, the modules below are
-necessary:
-        # USB Host Controller Drivers
-        #
-        CONFIG_USB_EHCI_HCD=m
-        CONFIG_USB_UHCI_HCD=m
-        CONFIG_USB_OHCI_HCD=m
-And finally:
-        # USB Multimedia devices
-        #
-        CONFIG_USB_ET61X251=m
-6. Module loading
-=================
-To use the driver, it is necessary to load the "et61x251" module into memory
-after every other module required: "videodev", "v4l2_common", "compat_ioctl32",
-"usbcore" and, depending on the USB host controller you have, "ehci-hcd",
-"uhci-hcd" or "ohci-hcd".
-Loading can be done as shown below:
-        [root@localhost home]# modprobe et61x251
-At this point the devices should be recognized. You can invoke "dmesg" to
-analyze kernel messages and verify that the loading process has gone well:
-        [user@localhost home]$ dmesg
-7. Module parameters
-====================
-Module parameters are listed below:
-------------------------------------------------------------------------------
-Name:           video_nr
-Type:           short array (min = 0, max = 64)
-Syntax:         <-1|n[,...]>
-Description:    Specify V4L2 minor mode number:
-                -1 = use next available
-                 n = use minor number n
-                You can specify up to 64 cameras this way.
-                For example:
-                video_nr=-1,2,-1 would assign minor number 2 to the second
-                registered camera and use auto for the first one and for every
-                other camera.
-Default:        -1
-------------------------------------------------------------------------------
-Name:           force_munmap
-Type:           bool array (min = 0, max = 64)
-Syntax:         <0|1[,...]>
-Description:    Force the application to unmap previously mapped buffer memory
-                before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not
-                all the applications support this feature. This parameter is
-                specific for each detected camera.
-                0 = do not force memory unmapping
-                1 = force memory unmapping (save memory)
-Default:        0
-------------------------------------------------------------------------------
-Name:           frame_timeout
-Type:           uint array (min = 0, max = 64)
-Syntax:         <n[,...]>
-Description:    Timeout for a video frame in seconds. This parameter is
-                specific for each detected camera. This parameter can be
-                changed at runtime thanks to the /sys filesystem interface.
-Default:        2
-------------------------------------------------------------------------------
-Name:           debug
-Type:           ushort
-Syntax:         <n>
-Description:    Debugging information level, from 0 to 3:
-                0 = none (use carefully)
-                1 = critical errors
-                2 = significant information
-                3 = more verbose messages
-                Level 3 is useful for testing only, when only one device
-                is used at the same time. It also shows some more information
-                about the hardware being detected. This module parameter can be
-                changed at runtime thanks to the /sys filesystem interface.
-Default:        2
-------------------------------------------------------------------------------
-8. Optional device control through "sysfs"
-==========================================
-If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled,
-it is possible to read and write both the ET61X[12]51 and the image sensor
-registers by using the "sysfs" filesystem interface.
-There are four files in the /sys/class/video4linux/videoX directory for each
-registered camera: "reg", "val", "i2c_reg" and "i2c_val". The first two files
-control the ET61X[12]51 bridge, while the other two control the sensor chip.
-"reg" and "i2c_reg" hold the values of the current register index where the
-following reading/writing operations are addressed at through "val" and
-"i2c_val". Their use is not intended for end-users, unless you know what you
-are doing. Remember that you must be logged in as root before writing to them.
-As an example, suppose we were to want to read the value contained in the
-register number 1 of the sensor register table - which is usually the product
-identifier - of the camera registered as "/dev/video0":
-        [root@localhost #] cd /sys/class/video4linux/video0
-        [root@localhost #] echo 1 > i2c_reg
-        [root@localhost #] cat i2c_val
-Note that if the sensor registers cannot be read, "cat" will fail.
-To avoid race conditions, all the I/O accesses to the files are serialized.
-9. Supported devices
-====================
-None of the names of the companies as well as their products will be mentioned
-here. They have never collaborated with the author, so no advertising.
-From the point of view of a driver, what unambiguously identify a device are
-its vendor and product USB identifiers. Below is a list of known identifiers of
-devices mounting the ET61X[12]51 PC camera controllers:
-Vendor ID  Product ID
---------  ----------
-0x102c     0x6151
-0x102c     0x6251
-0x102c     0x6253
-0x102c     0x6254
-0x102c     0x6255
-0x102c     0x6256
-0x102c     0x6257
-0x102c     0x6258
-0x102c     0x6259
-0x102c     0x625a
-0x102c     0x625b
-0x102c     0x625c
-0x102c     0x625d
-0x102c     0x625e
-0x102c     0x625f
-0x102c     0x6260
-0x102c     0x6261
-0x102c     0x6262
-0x102c     0x6263
-0x102c     0x6264
-0x102c     0x6265
-0x102c     0x6266
-0x102c     0x6267
-0x102c     0x6268
-0x102c     0x6269
-The following image sensors are supported:
-Model       Manufacturer
-----       ------------
-TAS5130D1B  Taiwan Advanced Sensor Corporation
-All the available control settings of each image sensor are supported through
-the V4L2 interface.
-10. Notes for V4L2 application developers
-=========================================
-This driver follows the V4L2 API specifications. In particular, it enforces two
-rules:
- exactly one I/O method, either "mmap" or "read", is associated with each
-file descriptor. Once it is selected, the application must close and reopen the
-device to switch to the other I/O method;
- although it is not mandatory, previously mapped buffer memory should always
-be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's.
-The same number of buffers as before will be allocated again to match the size
-of the new video frames, so you have to map the buffers again before any I/O
-attempts on them.
-Consistently with the hardware limits, this driver also supports image
-downscaling with arbitrary scaling factors from 1 and 2 in both directions.
-However, the V4L2 API specifications don't correctly define how the scaling
-factor can be chosen arbitrarily by the "negotiation" of the "source" and
-"target" rectangles. To work around this flaw, we have added the convention
-that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the
-scaling factor is restored to 1.
-This driver supports two different video formats: the first one is the "8-bit
-Sequential Bayer" format and can be used to obtain uncompressed video data
-from the device through the current I/O method, while the second one provides
-"raw" compressed video data (without frame headers not related to the
-compressed data). The current compression quality may vary from 0 to 1 and can
-be selected or queried thanks to the VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP
-V4L2 ioctl's.
-11. Contact information
-=======================
-The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
-GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is
-'FCE635A4'; the public 1024-bit key should be available at any keyserver;
-the fingerprint is: '88E8 F32F 7244 68BA 3958  5D40 99DA 5D2A FCE6 35A4'.
diff --git a/Documentation/video4linux/extract_xc3028.pl b/Documentation/video4linux/extract_xc3028.pl
index 47877deae6d7..47877deae6d7 100644..100755
--- a/Documentation/video4linux/extract_xc3028.pl
+++ b/Documentation/video4linux/extract_xc3028.pl
diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt
index fd02d9a4930a..25f4d3402722 100644
--- a/Documentation/video4linux/fimc.txt
+++ b/Documentation/video4linux/fimc.txt
@@ -58,7 +58,7 @@ Not currently supported:
 4.1. Media device interface
 The driver supports Media Controller API as defined at
-http://http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
+http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
 The media device driver name is "SAMSUNG S5P FIMC".
 The purpose of this interface is to allow changing assignment of FIMC instances
diff --git a/Documentation/video4linux/ibmcam.txt b/Documentation/video4linux/ibmcam.txt
deleted file mode 100644
index a51055211e62..000000000000
--- a/Documentation/video4linux/ibmcam.txt
+++ /dev/null
@@ -1,323 +0,0 @@
-README for Linux device driver for the IBM "C-It" USB video camera
-INTRODUCTION:
-This driver does not use all features known to exist in
-the IBM camera. However most of needed features work well.
-This driver was developed using logs of observed USB traffic
-which was produced by standard Windows driver (c-it98.sys).
-I did not have data sheets from Xirlink.
-Video formats:
-      128x96  [model 1]
-      176x144
-      320x240 [model 2]
-      352x240 [model 2]
-      352x288
-Frame rate: 3 - 30 frames per second (FPS)
-External interface: USB
-Internal interface: Video For Linux (V4L)
-Supported controls:
- by V4L: Contrast,  Brightness, Color, Hue
- by driver options: frame rate, lighting conditions, video format,
-                     default picture settings, sharpness.
-SUPPORTED CAMERAS:
-Xirlink "C-It" camera, also known as "IBM PC Camera".
-The device uses proprietary ASIC (and compression method);
-it is manufactured by Xirlink. See http://xirlinkwebcam.sourceforge.net, 
-http://www.ibmpccamera.com, or http://www.c-itnow.com/ for details and pictures.
-This very chipset ("X Chip", as marked at the factory)
-is used in several other cameras, and they are supported
-as well:
- IBM NetCamera
- Veo Stingray
-The Linux driver was developed with camera with following
-model number (or FCC ID): KSX-XVP510. This camera has three
-interfaces, each with one endpoint (control, iso, iso). This
-type of cameras is referred to as "model 1". These cameras are
-no longer manufactured.
-Xirlink now manufactures new cameras which are somewhat different.
-In particular, following models [FCC ID] belong to that category:
-XVP300 [KSX-X9903]
-XVP600 [KSX-X9902]
-XVP610 [KSX-X9902]
-(see http://www.xirlink.com/ibmpccamera/ for updates, they refer
-to these new cameras by Windows driver dated 12-27-99, v3005 BETA)
-These cameras have two interfaces, one endpoint in each (iso, bulk).
-Such type of cameras is referred to as "model 2". They are supported
-(with exception of 352x288 native mode).
-Some IBM NetCameras (Model 4) are made to generate only compressed
-video streams. This is great for performance, but unfortunately
-nobody knows how to decompress the stream :-( Therefore, these
-cameras are *unsupported* and if you try to use one of those, all
-you get is random colored horizontal streaks, not the image!
-If you have one of those cameras, you probably should return it
-to the store and get something that is supported.
-Tell me more about all that "model" business
--------------------------------------------
-I just invented model numbers to uniquely identify flavors of the
-hardware/firmware that were sold. It was very confusing to use
-brand names or some other internal numbering schemes. So I found
-by experimentation that all Xirlink chipsets fall into four big
-classes, and I called them "models". Each model is programmed in
-its own way, and each model sends back the video in its own way.
-Quirks of Model 2 cameras:
-------------------------
-Model 2 does not have hardware contrast control. Corresponding V4L
-control is implemented in software, which is not very nice to your
-CPU, but at least it works.
-This driver provides 352x288 mode by switching the camera into
-quasi-352x288 RGB mode (800 Kbits per frame) essentially limiting
-this mode to 10 frames per second or less, in ideal conditions on
-the bus (USB is shared, after all). The frame rate
-has to be programmed very conservatively. Additional concern is that
-frame rate depends on brightness setting; therefore the picture can
-be good at one brightness and broken at another! I did not want to fix
-the frame rate at slowest setting, but I had to move it pretty much down
-the scale (so that framerate option barely matters). I also noticed that
-camera after first powering up produces frames slightly faster than during
-consecutive uses. All this means that if you use 352x288 (which is
-default), be warned - you may encounter broken picture on first connect;
-try to adjust brightness - brighter image is slower, so USB will be able
-to send all data. However if you regularly use Model 2 cameras you may
-prefer 176x144 which makes perfectly good I420, with no scaling and
-lesser demands on USB (300 Kbits per second, or 26 frames per second).
-Another strange effect of 352x288 mode is the fine vertical grid visible
-on some colored surfaces. I am sure it is caused by me not understanding
-what the camera is trying to say. Blame trade secrets for that.
-The camera that I had also has a hardware quirk: if disconnected,
-it needs few minutes to "relax" before it can be plugged in again
-(poorly designed USB processor reset circuit?)
-[Veo Stingray with Product ID 0x800C is also Model 2, but I haven't
-observed this particular flaw in it.]
-Model 2 camera can be programmed for very high sensitivity (even starlight
-may be enough), this makes it convenient for tinkering with. The driver
-code has enough comments to help a programmer to tweak the camera
-as s/he feels necessary.
-WHAT YOU NEED:
- A supported IBM PC (C-it) camera (model 1 or 2)
- A Linux box with USB support (2.3/2.4; 2.2 w/backport may work)
- A Video4Linux compatible frame grabber program such as xawtv.
-HOW TO COMPILE THE DRIVER:
-You need to compile the driver only if you are a developer
-or if you want to make changes to the code. Most distributions
-precompile all modules, so you can go directly to the next
-section "HOW TO USE THE DRIVER".
-The ibmcam driver uses usbvideo helper library (module),
-so if you are studying the ibmcam code you will be led there.
-The driver itself consists of only one file in usb/ directory:
-ibmcam.c. This file is included into the Linux kernel build
-process if you configure the kernel for CONFIG_USB_IBMCAM.
-Run "make xconfig" and in USB section you will find the IBM
-camera driver. Select it, save the configuration and recompile.
-HOW TO USE THE DRIVER:
-I recommend to compile driver as a module. This gives you an
-easier access to its configuration. The camera has many more
-settings than V4L can operate, so some settings are done using
-module options.
-To begin with, on most modern Linux distributions the driver
-will be automatically loaded whenever you plug the supported
-camera in. Therefore, you don't need to do anything. However
-if you want to experiment with some module parameters then
-you can load and unload the driver manually, with camera
-plugged in or unplugged.
-Typically module is installed with command 'modprobe', like this:
-# modprobe ibmcam framerate=1
-Alternatively you can use 'insmod' in similar fashion:
-# insmod /lib/modules/2.x.y/usb/ibmcam.o framerate=1
-Module can be inserted with camera connected or disconnected.
-The driver can have options, though some defaults are provided.
-Driver options: (* indicates that option is model-dependent)
-Name            Type            Range [default] Example
--------------  --------------  --------------  ------------------
-debug           Integer         0-9 [0]         debug=1
-flags           Integer         0-0xFF [0]      flags=0x0d
-framerate       Integer         0-6 [2]         framerate=1
-hue_correction  Integer         0-255 [128]     hue_correction=115
-init_brightness Integer         0-255 [128]     init_brightness=100
-init_contrast   Integer         0-255 [192]     init_contrast=200
-init_color      Integer         0-255 [128]     init_color=130
-init_hue        Integer         0-255 [128]     init_hue=115
-lighting        Integer         0-2* [1]        lighting=2
-sharpness       Integer         0-6* [4]        sharpness=3
-size            Integer         0-2* [2]        size=1
-Options for Model 2 only:
-Name            Type            Range [default] Example
--------------  --------------  --------------  ------------------
-init_model2_rg  Integer         0..255 [0x70]   init_model2_rg=128
-init_model2_rg2 Integer         0..255 [0x2f]   init_model2_rg2=50
-init_model2_sat Integer         0..255 [0x34]   init_model2_sat=65
-init_model2_yb  Integer         0..255 [0xa0]   init_model2_yb=200
-debug           You don't need this option unless you are a developer.
-                If you are a developer then you will see in the code
-                what values do what. 0=off.
-flags           This is a bit mask, and you can combine any number of
-                bits to produce what you want. Usually you don't want
-                any of extra features this option provides:
-                FLAGS_RETRY_VIDIOCSYNC  1  This bit allows to retry failed
-                                           VIDIOCSYNC ioctls without failing.
-                                           Will work with xawtv, will not
-                                           with xrealproducer. Default is
-                                           not set.
-                FLAGS_MONOCHROME        2  Activates monochrome (b/w) mode.
-                FLAGS_DISPLAY_HINTS     4  Shows colored pixels which have
-                                           magic meaning to developers.
-                FLAGS_OVERLAY_STATS     8  Shows tiny numbers on screen,
-                                           useful only for debugging.
-                FLAGS_FORCE_TESTPATTERN 16 Shows blue screen with numbers.
-                FLAGS_SEPARATE_FRAMES   32 Shows each frame separately, as
-                                           it was received from the camera.
-                                           Default (not set) is to mix the
-                                           preceding frame in to compensate
-                                           for occasional loss of Isoc data
-                                           on high frame rates.
-                FLAGS_CLEAN_FRAMES      64 Forces "cleanup" of each frame
-                                           prior to use; relevant only if
-                                           FLAGS_SEPARATE_FRAMES is set.
-                                           Default is not to clean frames,
-                                           this is a little faster but may
-                                           produce flicker if frame rate is
-                                           too high and Isoc data gets lost.
-                FLAGS_NO_DECODING      128 This flag turns the video stream
-                                           decoder off, and dumps the raw
-                                           Isoc data from the camera into
-                                           the reading process. Useful to
-                                           developers, but not to users.
-framerate       This setting controls frame rate of the camera. This is
-                an approximate setting (in terms of "worst" ... "best")
-                because camera changes frame rate depending on amount
-                of light available. Setting 0 is slowest, 6 is fastest.
-                Beware - fast settings are very demanding and may not
-                work well with all video sizes. Be conservative.
-hue_correction  This highly optional setting allows to adjust the
-                hue of the image in a way slightly different from
-                what usual "hue" control does. Both controls affect
-                YUV colorspace: regular "hue" control adjusts only
-                U component, and this "hue_correction" option similarly
-                adjusts only V component. However usually it is enough
-                to tweak only U or V to compensate for colored light or
-                color temperature; this option simply allows more
-                complicated correction when and if it is necessary.
-init_brightness These settings specify _initial_ values which will be
-init_contrast   used to set up the camera. If your V4L application has
-init_color      its own controls to adjust the picture then these
-init_hue        controls will be used too. These options allow you to
-                preconfigure the camera when it gets connected, before
-                any V4L application connects to it. Good for webcams.
-init_model2_rg  These initial settings alter color balance of the
-init_model2_rg2 camera on hardware level. All four settings may be used
-init_model2_sat to tune the camera to specific lighting conditions. These
-init_model2_yb  settings only apply to Model 2 cameras.
-lighting        This option selects one of three hardware-defined
-                photosensitivity settings of the camera. 0=bright light,
-                1=Medium (default), 2=Low light. This setting affects
-                frame rate: the dimmer the lighting the lower the frame
-                rate (because longer exposition time is needed). The
-                Model 2 cameras allow values more than 2 for this option,
-                thus enabling extremely high sensitivity at cost of frame
-                rate, color saturation and imaging sensor noise.
-sharpness       This option controls smoothing (noise reduction)
-                made by camera. Setting 0 is most smooth, setting 6
-                is most sharp. Be aware that CMOS sensor used in the
-                camera is pretty noisy, so if you choose 6 you will
-                be greeted with "snowy" image. Default is 4. Model 2
-                cameras do not support this feature.
-size            This setting chooses one of several image sizes that are
-                supported by this driver. Cameras may support more, but
-                it's difficult to reverse-engineer all formats.
-                Following video sizes are supported:
-                size=0     128x96  (Model 1 only)
-                size=1     160x120
-                size=2     176x144
-                size=3     320x240 (Model 2 only)
-                size=4     352x240 (Model 2 only)
-                size=5     352x288
-                size=6     640x480 (Model 3 only)
-                The 352x288 is the native size of the Model 1 sensor
-                array, so it's the best resolution the camera can
-                yield. The best resolution of Model 2 is 176x144, and
-                larger images are produced by stretching the bitmap.
-                Model 3 has sensor with 640x480 grid, and it works too,
-                but the frame rate will be exceptionally low (1-2 FPS);
-                it may be still OK for some applications, like security.
-                Choose the image size you need. The smaller image can
-                support faster frame rate. Default is 352x288.
-For more information and the Troubleshooting FAQ visit this URL:
-                http://www.linux-usb.org/ibmcam/
-WHAT NEEDS TO BE DONE:
- The button on the camera is not used. I don't know how to get to it.
-  I know now how to read button on Model 2, but what to do with it?
- Camera reports its status back to the driver; however I don't know
-  what returned data means. If camera fails at some initialization
-  stage then something should be done, and I don't do that because
-  I don't even know that some command failed. This is mostly Model 1
-  concern because Model 2 uses different commands which do not return
-  status (and seem to complete successfully every time).
- Some flavors of Model 4 NetCameras produce only compressed video
-  streams, and I don't know how to decode them.
-CREDITS:
-The code is based in no small part on the CPiA driver by Johannes Erdfelt,
-Randy Dunlap, and others. Big thanks to them for their pioneering work on that
-and the USB stack.
-I also thank John Lightsey for his donation of the Veo Stingray camera.
diff --git a/Documentation/video4linux/m5602.txt b/Documentation/video4linux/m5602.txt
deleted file mode 100644
index 4450ab13f37b..000000000000
--- a/Documentation/video4linux/m5602.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-This document describes the ALi m5602 bridge connected
-to the following supported sensors:
-OmniVision OV9650,
-Samsung s5k83a,
-Samsung s5k4aa,
-Micron mt9m111,
-Pixel plus PO1030
-This driver mimics the windows drivers, which have a braindead implementation sending bayer-encoded frames at VGA resolution.
-In a perfect world we should be able to reprogram the m5602 and the connected sensor in hardware instead, supporting a range of resolutions and pixelformats
-Anyway, have fun and please report any bugs to m560x-driver-devel@lists.sourceforge.net
diff --git a/Documentation/video4linux/ov511.txt b/Documentation/video4linux/ov511.txt
deleted file mode 100644
index b3326b167ada..000000000000
--- a/Documentation/video4linux/ov511.txt
+++ /dev/null
@@ -1,288 +0,0 @@
-------------------------------------------------------------------------------
-Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC
-------------------------------------------------------------------------------
-Author: Mark McClelland
-Homepage: http://alpha.dyndns.org/ov511
-INTRODUCTION:
-This is a driver for the OV511, a USB-only chip used in many "webcam" devices.
-Any camera using the OV511/OV511+ and the OV6620/OV7610/20/20AE should work.
-Video capture devices that use the Philips SAA7111A decoder also work. It
-supports streaming and capture of color or monochrome video via the Video4Linux
-API. Most V4L apps are compatible with it. Most resolutions with a width and
-height that are a multiple of 8 are supported.
-If you need more information, please visit the OV511 homepage at the above URL.
-WHAT YOU NEED:
- If you want to help with the development, get the chip's specification docs at
-  http://www.ovt.com/omniusbp.html
- A Video4Linux compatible frame grabber program (I recommend vidcat and xawtv)
-    vidcat is part of the w3cam package:  http://mpx.freeshell.net/
-    xawtv is available at:  http://linux.bytesex.org/xawtv/
-HOW TO USE IT:
-Note: These are simplified instructions. For complete instructions see:
-        http://alpha.dyndns.org/ov511/install.html
-You must have first compiled USB support, support for your specific USB host
-controller (UHCI or OHCI), and Video4Linux support for your kernel (I recommend
-making them modules.) Make sure "Enforce bandwidth allocation" is NOT enabled.
-Next, (as root):
-        modprobe usbcore
-        modprobe usb-uhci  <OR>  modprobe usb-ohci
-        modprobe videodev
-        modprobe ov511
-If it is not already there (it usually is), create the video device:
-        mknod /dev/video0 c 81 0
-Optionally, symlink /dev/video to /dev/video0
-You will have to set permissions on this device to allow you to read/write
-from it:
-        chmod 666 /dev/video
-        chmod 666 /dev/video0 (if necessary)
-Now you are ready to run a video app! Both vidcat and xawtv work well for me
-at 640x480.
-[Using vidcat:]
-        vidcat -s 640x480 -p c > test.jpg
-        xview test.jpg
-[Using xawtv:]
-From the main xawtv directory:
-        make clean
-        ./configure
-        make
-        make install
-Now you should be able to run xawtv. Right click for the options dialog.
-MODULE PARAMETERS:
-  You can set these with:  insmod ov511 NAME=VALUE
-  There is currently no way to set these on a per-camera basis.
-  NAME: autobright
-  TYPE: integer (Boolean)
-  DEFAULT: 1
-  DESC: Brightness is normally under automatic control and can't be set
-        manually by the video app. Set to 0 for manual control.
-  NAME: autogain
-  TYPE: integer (Boolean)
-  DEFAULT: 1
-  DESC: Auto Gain Control enable. This feature is not yet implemented.
-  NAME: autoexp
-  TYPE: integer (Boolean)
-  DEFAULT: 1
-  DESC: Auto Exposure Control enable. This feature is not yet implemented.
-  NAME: debug
-  TYPE: integer (0-6)
-  DEFAULT: 3
-  DESC: Sets the threshold for printing debug messages. The higher the value,
-        the more is printed. The levels are cumulative, and are as follows:
-          0=no debug messages
-          1=init/detection/unload and other significant messages
-          2=some warning messages
-          3=config/control function calls
-          4=most function calls and data parsing messages
-          5=highly repetitive mesgs
-  NAME: snapshot
-  TYPE: integer (Boolean)
-  DEFAULT: 0
-  DESC: Set to 1 to enable snapshot mode. read()/VIDIOCSYNC will block until
-        the snapshot button is pressed. Note: enabling this mode disables
-        /proc/video/ov511/<minor#>/button
-  NAME: cams
-  TYPE: integer (1-4 for OV511, 1-31 for OV511+)
-  DEFAULT: 1
-  DESC: Number of cameras allowed to stream simultaneously on a single bus.
-        Values higher than 1 reduce the data rate of each camera, allowing two
-        or more to be used at once. If you have a complicated setup involving
-        both OV511 and OV511+ cameras, trial-and-error may be necessary for
-        finding the optimum setting.
-  NAME: compress
-  TYPE: integer (Boolean)
-  DEFAULT: 0
-  DESC: Set this to 1 to turn on the camera's compression engine. This can
-        potentially increase the frame rate at the expense of quality, if you
-        have a fast CPU. You must load the proper compression module for your
-        camera before starting your application (ov511_decomp or ov518_decomp).
-  NAME: testpat
-  TYPE: integer (Boolean)
-  DEFAULT: 0
-  DESC: This configures the camera's sensor to transmit a colored test-pattern
-        instead of an image. This does not work correctly yet.
-  NAME: dumppix
-  TYPE: integer (0-2)
-  DEFAULT: 0
-  DESC: Dumps raw pixel data and skips post-processing and format conversion.
-        It is for debugging purposes only. Options are:
-                0: Disable (default)
-                1: Dump raw data from camera, excluding headers and trailers
-                2: Dumps data exactly as received from camera
-  NAME: led
-  TYPE: integer (0-2)
-  DEFAULT: 1 (Always on)
-  DESC: Controls whether the LED (the little light) on the front of the camera
-        is always off (0), always on (1), or only on when driver is open (2).
-        This is not supported with the OV511, and might only work with certain
-        cameras (ones that actually have the LED wired to the control pin, and
-        not just hard-wired to be on all the time).
-  NAME: dump_bridge
-  TYPE: integer (Boolean)
-  DEFAULT: 0
-  DESC: Dumps the bridge (OV511[+] or OV518[+]) register values to the system
-        log. Only useful for serious debugging/development purposes.
-  NAME: dump_sensor
-  TYPE: integer (Boolean)
-  DEFAULT: 0
-  DESC: Dumps the sensor register values to the system log. Only useful for
-        serious debugging/development purposes.
-  NAME: printph
-  TYPE: integer (Boolean)
-  DEFAULT: 0
-  DESC: Setting this to 1 will dump the first 12 bytes of each isoc frame. This
-        is only useful if you are trying to debug problems with the isoc data
-        stream (i.e.: camera initializes, but vidcat hangs until Ctrl-C). Be
-        warned that this dumps a large number of messages to your kernel log.
-  NAME: phy, phuv, pvy, pvuv, qhy, qhuv, qvy, qvuv
-  TYPE: integer (0-63 for phy and phuv, 0-255 for rest)
-  DEFAULT: OV511 default values
-  DESC: These are registers 70h - 77h of the OV511, which control the
-        prediction ranges and quantization thresholds of the compressor, for
-        the Y and UV channels in the horizontal and vertical directions. See
-        the OV511 or OV511+ data sheet for more detailed descriptions. These
-        normally do not need to be changed.
-  NAME: lightfreq
-  TYPE: integer (0, 50, or 60)
-  DEFAULT: 0 (use sensor default)
-  DESC: Sets the sensor to match your lighting frequency. This can reduce the
-        appearance of "banding", i.e. horizontal lines or waves of light and
-        dark that are often caused by artificial lighting. Valid values are:
-                0 - Use default (depends on sensor, most likely 60 Hz)
-                50 - For European and Asian 50 Hz power
-                60 - For American 60 Hz power
-  NAME: bandingfilter
-  TYPE: integer (Boolean)
-  DEFAULT: 0 (off)
-  DESC: Enables the sensor´s banding filter exposure algorithm. This reduces
-        or stabilizes the "banding" caused by some artificial light sources
-        (especially fluorescent). You might have to set lightfreq correctly for
-        this to work right. As an added bonus, this sometimes makes it
-        possible to capture your monitor´s output.
-  NAME: fastset
-  TYPE: integer (Boolean)
-  DEFAULT: 0 (off)
-  DESC: Allows picture settings (brightness, contrast, color, and hue) to take
-        effect immediately, even in the middle of a frame. This reduces the
-        time to change settings, but can ruin frames during the change. Only
-        affects OmniVision sensors.
-  NAME: force_palette
-  TYPE: integer (Boolean)
-  DEFAULT: 0 (off)
-  DESC: Forces the palette (color format) to a specific value. If an
-        application requests a different palette, it will be rejected, thereby
-        forcing it to try others until it succeeds. This is useful for forcing
-        greyscale mode with a color camera, for example. Supported modes are:
-                0                           (Allows all the following formats)
-                1   VIDEO_PALETTE_GREY      (Linear greyscale)
-                10  VIDEO_PALETTE_YUV420    (YUV 4:2:0 Planar)
-                15  VIDEO_PALETTE_YUV420P   (YUV 4:2:0 Planar, same as 10)
-  NAME: backlight
-  TYPE: integer (Boolean)
-  DEFAULT: 0 (off)
-  DESC: Setting this flag changes the exposure algorithm for OmniVision sensors
-        such that objects in the camera's view (i.e. your head) can be clearly
-        seen when they are illuminated from behind. It reduces or eliminates
-        the sensor's auto-exposure function, so it should only be used when
-        needed. Additionally, it is only supported with the OV6620 and OV7620.
-  NAME: unit_video
-  TYPE: Up to 16 comma-separated integers
-  DEFAULT: 0,0,0... (automatically assign the next available minor(s))
-  DESC: You can specify up to 16 minor numbers to be assigned to ov511 devices.
-        For example, "unit_video=1,3" will make the driver use /dev/video1 and
-        /dev/video3 for the first two devices it detects. Additional devices
-        will be assigned automatically starting at the first available device
-        node (/dev/video0 in this case). Note that you cannot specify 0 as a
-        minor number. This feature requires kernel version 2.4.5 or higher.
-  NAME: remove_zeros
-  TYPE: integer (Boolean)
-  DEFAULT: 0 (do not skip any incoming data)
-  DESC: Setting this to 1 will remove zero-padding from incoming data. This
-        will compensate for the blocks of corruption that can appear when the
-        camera cannot keep up with the speed of the USB bus (eg. at low frame
-        resolutions). This feature is always enabled when compression is on.
-  NAME: mirror
-  TYPE: integer (Boolean)
-  DEFAULT: 0 (off)
-  DESC: Setting this to 1 will reverse ("mirror") the image horizontally. This
-        might be necessary if your camera has a custom lens assembly. This has
-        no effect with video capture devices.
-  NAME: ov518_color
-  TYPE: integer (Boolean)
-  DEFAULT: 0 (off)
-  DESC: Enable OV518 color support. This is off by default since it doesn't
-        work most of the time. If you want to try it, you must also load
-        ov518_decomp with the "nouv=0" parameter. If you get improper colors or
-        diagonal lines through the image, restart your video app and try again.
-        Repeat as necessary.
-WORKING FEATURES:
- o Color streaming/capture at most widths and heights that are multiples of 8.
- o Monochrome (use force_palette=1 to enable)
- o Setting/getting of saturation, contrast, brightness, and hue (only some of
-   them work the OV7620 and OV7620AE)
- o /proc status reporting
- o SAA7111A video capture support at 320x240 and 640x480
- o Compression support
- o SMP compatibility
-HOW TO CONTACT ME:
-You can email me at mark@alpha.dyndns.org . Please prefix the subject line
-with "OV511: " so that I am certain to notice your message.
-CREDITS:
-The code is based in no small part on the CPiA driver by Johannes Erdfelt,
-Randy Dunlap, and others. Big thanks to them for their pioneering work on that
-and the USB stack. Thanks to Bret Wallach for getting camera reg IO, ISOC, and
-image capture working. Thanks to Orion Sky Lawlor, Kevin Moore, and Claudio
-Matsuoka for their work as well.
diff --git a/Documentation/video4linux/se401.txt b/Documentation/video4linux/se401.txt
deleted file mode 100644
index bd6526ec8dd7..000000000000
--- a/Documentation/video4linux/se401.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-Linux driver for SE401 based USB cameras
-Copyright, 2001, Jeroen Vreeken
-INTRODUCTION:
-The SE401 chip is the used in low-cost usb webcams.
-It is produced by Endpoints Inc. (www.endpoints.com).
-It interfaces directly to a cmos image sensor and USB. The only other major
-part in a se401 based camera is a dram chip.
-The following cameras are known to work with this driver:
-Aox se401 (non-branded) cameras
-Philips PVCV665 USB VGA webcam 'Vesta Fun'
-Kensington VideoCAM PC Camera Model 67014
-Kensington VideoCAM PC Camera Model 67015
-Kensington VideoCAM PC Camera Model 67016
-Kensington VideoCAM PC Camera Model 67017
-WHAT YOU NEED:
-       USB support
-       VIDEO4LINUX support
-More information about USB support for linux can be found at:
-http://www.linux-usb.org
-MODULE OPTIONS:
-When the driver is compiled as a module you can also use the 'flickerless'
-option. With it exposure is limited to values that do not interfere with the
-net frequency. Valid options for this option are 0, 50 and 60. (0=disable,
-50=50hz, 60=60hz)
-KNOWN PROBLEMS:
-The driver works fine with the usb-ohci and uhci host controller drivers,
-the default settings also work with usb-uhci. But sending more than one bulk
-transfer at a time with usb-uhci doesn't work yet.
-Users of usb-ohci and uhci can safely enlarge SE401_NUMSBUF in se401.h in
-order to increase the throughput (and thus framerate).
-HELP:
-The latest info on this driver can be found at:
-http://members.chello.nl/~j.vreeken/se401/
-And questions to me can be send to:
-pe1rxq@amsat.org
diff --git a/Documentation/video4linux/si470x.txt b/Documentation/video4linux/si470x.txt
index 3a7823e01b4d..98c32925eb39 100644
--- a/Documentation/video4linux/si470x.txt
+++ b/Documentation/video4linux/si470x.txt
@@ -53,6 +53,9 @@ Testing is usually done with most application under Debian/testing:
 - kradio - Comfortable Radio Application for KDE
 - radio - ncurses-based radio application
 - mplayer - The Ultimate Movie Player For Linux
+- v4l2-ctl - Collection of command line video4linux utilities
+For example, you can use:
+v4l2-ctl -d /dev/radio0 --set-ctrl=volume=10,mute=0 --set-freq=95.21 --all
 There is also a library libv4l, which can be used. It's going to have a function
 for frequency seeking, either by using hardware functionality as in radio-si470x
@@ -75,8 +78,10 @@ commands. Please adjust the audio devices to your needs (/dev/dsp* and hw:x,x).
 If you just want to test audio (very poor quality):
 cat /dev/dsp1 > /dev/dsp
-If you use OSS try:
+If you use sox + OSS try:
 sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp
+or using sox + alsa:
+sox --endian little -c 2 -S -r 96000 -t alsa hw:1 -t alsa -r 96000 hw:0
 If you use arts try:
 arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B -
diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt
index 3f87c7da4ca2..f62fcdbc8b9f 100644
--- a/Documentation/video4linux/soc-camera.txt
+++ b/Documentation/video4linux/soc-camera.txt
@@ -9,32 +9,36 @@ The following terms are used in this document:
   of connecting to a variety of systems and interfaces, typically uses i2c for
   control and configuration, and a parallel or a serial bus for data.
 - camera host - an interface, to which a camera is connected. Typically a
-   specialised interface, present on many SoCs, e.g., PXA27x and PXA3xx, SuperH,
+   specialised interface, present on many SoCs, e.g. PXA27x and PXA3xx, SuperH,
   AVR32, i.MX27, i.MX31.
 - camera host bus - a connection between a camera host and a camera. Can be
-   parallel or serial, consists of data and control lines, e.g., clock, vertical
+   parallel or serial, consists of data and control lines, e.g. clock, vertical
   and horizontal synchronization signals.
 Purpose of the soc-camera subsystem
 -----------------------------------
-The soc-camera subsystem provides a unified API between camera host drivers and
+The soc-camera subsystem initially provided a unified API between camera host
-camera sensor drivers. It implements a V4L2 interface to the user, currently
+drivers and camera sensor drivers. Later the soc-camera sensor API has been
-only the mmap method is supported.
+replaced with the V4L2 standard subdev API. This also made camera driver re-use
+with non-soc-camera hosts possible. The camera host API to the soc-camera core
+has been preserved.
-This subsystem has been written to connect drivers for System-on-Chip (SoC)
+Soc-camera implements a V4L2 interface to the user, currently only the "mmap"
-video capture interfaces with drivers for CMOS camera sensor chips to enable
+method is supported by host drivers. However, the soc-camera core also provides
-the reuse of sensor drivers with various hosts. The subsystem has been designed
+support for the "read" method.
-to support multiple camera host interfaces and multiple cameras per interface,
-although most applications have only one camera sensor.
+The subsystem has been designed to support multiple camera host interfaces and
+multiple cameras per interface, although most applications have only one camera
+sensor.
 Existing drivers
 ----------------
-As of 2.6.27-rc4 there are two host drivers in the mainline: pxa_camera.c for
+As of 3.7 there are seven host drivers in the mainline: atmel-isi.c,
-PXA27x SoCs and sh_mobile_ceu_camera.c for SuperH SoCs, and four sensor drivers:
+mx1_camera.c (broken, scheduled for removal), mx2_camera.c, mx3_camera.c,
-mt9m001.c, mt9m111.c, mt9v022.c and a generic soc_camera_platform.c driver. This
+omap1_camera.c, pxa_camera.c, sh_mobile_ceu_camera.c, and multiple sensor
-list is not supposed to be updated, look for more examples in your tree.
+drivers under drivers/media/i2c/soc_camera/.
 Camera host API
 ---------------
@@ -45,38 +49,37 @@ soc_camera_host_register(struct soc_camera_host *);
 function. The host object can be initialized as follows:
-static struct soc_camera_host pxa_soc_camera_host = {
+        struct soc_camera_host  *ici;
-        .drv_name       = PXA_CAM_DRV_NAME,
+        ici->drv_name           = DRV_NAME;
-        .ops            = &pxa_soc_camera_host_ops,
+        ici->ops                = &camera_host_ops;
-};
+        ici->priv               = pcdev;
+        ici->v4l2_dev.dev       = &pdev->dev;
+        ici->nr                 = pdev->id;
 All camera host methods are passed in a struct soc_camera_host_ops:
-static struct soc_camera_host_ops pxa_soc_camera_host_ops = {
+static struct soc_camera_host_ops camera_host_ops = {
        .owner          = THIS_MODULE,
-        .add            = pxa_camera_add_device,
+        .add            = camera_add_device,
-        .remove         = pxa_camera_remove_device,
+        .remove         = camera_remove_device,
-        .suspend        = pxa_camera_suspend,
+        .set_fmt        = camera_set_fmt_cap,
-        .resume         = pxa_camera_resume,
+        .try_fmt        = camera_try_fmt_cap,
-        .set_fmt_cap    = pxa_camera_set_fmt_cap,
+        .init_videobuf2 = camera_init_videobuf2,
-        .try_fmt_cap    = pxa_camera_try_fmt_cap,
+        .poll           = camera_poll,
-        .init_videobuf  = pxa_camera_init_videobuf,
+        .querycap       = camera_querycap,
-        .reqbufs        = pxa_camera_reqbufs,
+        .set_bus_param  = camera_set_bus_param,
-        .poll           = pxa_camera_poll,
+        /* The rest of host operations are optional */
-        .querycap       = pxa_camera_querycap,
-        .try_bus_param  = pxa_camera_try_bus_param,
-        .set_bus_param  = pxa_camera_set_bus_param,
 };
 .add and .remove methods are called when a sensor is attached to or detached
-from the host, apart from performing host-internal tasks they shall also call
+from the host. .set_bus_param is used to configure physical connection
-sensor driver's .init and .release methods respectively. .suspend and .resume
+parameters between the host and the sensor. .init_videobuf2 is called by
-methods implement host's power-management functionality and its their
+soc-camera core when a video-device is opened, the host driver would typically
-responsibility to call respective sensor's methods. .try_bus_param and
+call vb2_queue_init() in this method. Further video-buffer management is
-.set_bus_param are used to negotiate physical connection parameters between the
+implemented completely by the specific camera host driver. If the host driver
-host and the sensor. .init_videobuf is called by soc-camera core when a
+supports non-standard pixel format conversion, it should implement a
-video-device is opened, further video-buffer management is implemented completely
+.get_formats and, possibly, a .put_formats operations. See below for more
-by the specific camera host driver. The rest of the methods are called from
+details about format conversion. The rest of the methods are called from
 respective V4L2 operations.
 Camera API
@@ -84,37 +87,21 @@ Camera API
 Sensor drivers can use struct soc_camera_link, typically provided by the
 platform, and used to specify to which camera host bus the sensor is connected,
-and arbitrarily provide platform .power and .reset methods for the camera.
+and optionally provide platform .power and .reset methods for the camera. This
-soc_camera_device_register() and soc_camera_device_unregister() functions are
+struct is provided to the camera driver via the I2C client device platform data
-used to add a sensor driver to or remove one from the system. The registration
+and can be obtained, using the soc_camera_i2c_to_link() macro. Care should be
-function takes a pointer to struct soc_camera_device as the only parameter.
+taken, when using soc_camera_vdev_to_subdev() and when accessing struct
-This struct can be initialized as follows:
+soc_camera_device, using v4l2_get_subdev_hostdata(): both only work, when
+running on an soc-camera host. The actual camera driver operation is implemented
-        /* link to driver operations */
+using the V4L2 subdev API. Additionally soc-camera camera drivers can use
-        icd->ops        = &mt9m001_ops;
+auxiliary soc-camera helper functions like soc_camera_power_on() and
-        /* link to the underlying physical (e.g., i2c) device */
+soc_camera_power_off(), which switch regulators, provided by the platform and call
-        icd->control    = &client->dev;
+board-specific power switching methods. soc_camera_apply_board_flags() takes
-        /* window geometry */
+camera bus configuration capability flags and applies any board transformations,
-        icd->x_min      = 20;
+e.g. signal polarity inversion. soc_mbus_get_fmtdesc() can be used to obtain a
-        icd->y_min      = 12;
+pixel format descriptor, corresponding to a certain media-bus pixel format code.
-        icd->x_current  = 20;
+soc_camera_limit_side() can be used to restrict beginning and length of a frame
-        icd->y_current  = 12;
+side, based on camera capabilities.
-        icd->width_min  = 48;
-        icd->width_max  = 1280;
-        icd->height_min = 32;
-        icd->height_max = 1024;
-        icd->y_skip_top = 1;
-        /* camera bus ID, typically obtained from platform data */
-        icd->iface      = icl->bus_id;
-struct soc_camera_ops provides .probe and .remove methods, which are called by
-the soc-camera core, when a camera is matched against or removed from a camera
-host bus, .init, .release, .suspend, and .resume are called from the camera host
-driver as discussed above. Other members of this struct provide respective V4L2
-functionality.
-struct soc_camera_device also links to an array of struct soc_camera_data_format,
-listing pixel formats, supported by the camera.
 VIDIOC_S_CROP and VIDIOC_S_FMT behaviour
 ----------------------------------------
@@ -153,8 +140,25 @@ implemented.
 User window geometry is kept in .user_width and .user_height fields in struct
 soc_camera_device and used by the soc-camera core and host drivers. The core
 updates these fields upon successful completion of a .s_fmt() call, but if these
-fields change elsewhere, e.g., during .s_crop() processing, the host driver is
+fields change elsewhere, e.g. during .s_crop() processing, the host driver is
 responsible for updating them.
+Format conversion
+-----------------
+V4L2 distinguishes between pixel formats, as they are stored in memory, and as
+they are transferred over a media bus. Soc-camera provides support to
+conveniently manage these formats. A table of standard transformations is
+maintained by soc-camera core, which describes, what FOURCC pixel format will
+be obtained, if a media-bus pixel format is stored in memory according to
+certain rules. E.g. if V4L2_MBUS_FMT_YUYV8_2X8 data is sampled with 8 bits per
+sample and stored in memory in the little-endian order with no gaps between
+bytes, data in memory will represent the V4L2_PIX_FMT_YUYV FOURCC format. These
+standard transformations will be used by soc-camera or by camera host drivers to
+configure camera drivers to produce the FOURCC format, requested by the user,
+using the VIDIOC_S_FMT ioctl(). Apart from those standard format conversions,
+host drivers can also provide their own conversion rules by implementing a
+.get_formats and, if required, a .put_formats methods.
 --
 Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
diff --git a/Documentation/video4linux/stv680.txt b/Documentation/video4linux/stv680.txt
deleted file mode 100644
index e3de33645308..000000000000
--- a/Documentation/video4linux/stv680.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Linux driver for STV0680 based USB cameras
-Copyright, 2001, Kevin Sisson
-INTRODUCTION:
-STMicroelectronics produces the STV0680B chip, which comes in two
-types, -001 and -003. The -003 version allows the recording and downloading
-of sound clips from the camera, and allows a flash attachment. Otherwise,
-it uses the same commands as the -001 version. Both versions support a
-variety of SDRAM sizes and sensors, allowing for a maximum of 26 VGA or 20
-CIF pictures. The STV0680 supports either a serial or a usb interface, and
-video is possible through the usb interface.
-The following cameras are known to work with this driver, although any
-camera with Vendor/Product codes of 0553/0202 should work:
-Aiptek Pencam (various models)
-Nisis QuickPix 2
-Radio Shack 'Kid's digital camera' (#60-1207)
-At least one Trust Spycam model
-Several other European brand models
-WHAT YOU NEED:
-       USB support
-       VIDEO4LINUX support
-More information about USB support for linux can be found at:
-http://www.linux-usb.org
-MODULE OPTIONS:
-When the driver is compiled as a module, you can set a "swapRGB=1"
-option, if necessary, for those applications that require it
-(such as xawtv). However, the driver should detect and set this
-automatically, so this option should not normally be used.
-KNOWN PROBLEMS:
-The driver seems to work better with the usb-ohci than the usb-uhci host
-controller driver.
-HELP:
-The latest info on this driver can be found at:
-http://personal.clt.bellsouth.net/~kjsisson or at
-http://stv0680-usb.sourceforge.net
-Any questions to me can be send to:  kjsisson@bellsouth.net
diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt
index cfe52c798d74..676f87366025 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -715,14 +715,20 @@ a control of this type whenever the first control belonging to a new control
 class is added.
-Proposals for Extensions
+Adding Notify Callbacks
-========================
+=======================
+Sometimes the platform or bridge driver needs to be notified when a control
+from a sub-device driver changes. You can set a notify callback by calling
+this function:
-Some ideas for future extensions to the spec:
+void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl,
+        void (*notify)(struct v4l2_ctrl *ctrl, void *priv), void *priv);
-1) Add a V4L2_CTRL_FLAG_HEX to have values shown as hexadecimal instead of
+Whenever the give control changes value the notify callback will be called
-decimal. Useful for e.g. video_mute_yuv.
+with a pointer to the control and the priv pointer that was passed with
+v4l2_ctrl_notify. Note that the control's handler lock is held when the
+notify function is called.
-2) It is possible to mark in the controls array which controls have been
+There can be only one notify function per control handler. Any attempt
-successfully written and which failed by for example adding a bit to the
+to set another notify function will cause a WARN_ON.
-control ID. Not sure if it is worth the effort, though.
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index b89567ad04b7..a300b283a1a0 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -68,8 +68,7 @@ Structure of the framework
 The framework closely resembles the driver structure: it has a v4l2_device
 struct for the device instance data, a v4l2_subdev struct to refer to
 sub-device instances, the video_device struct stores V4L2 device node data
-and in the future a v4l2_fh struct will keep track of filehandle instances
+and the v4l2_fh struct keeps track of filehandle instances.
-(this is not yet implemented).
 The V4L2 framework also optionally integrates with the media framework. If a
 driver sets the struct v4l2_device mdev field, sub-devices and video nodes
diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt
deleted file mode 100644
index 9649450f3b90..000000000000
--- a/Documentation/video4linux/w9968cf.txt
+++ /dev/null
@@ -1,458 +0,0 @@
-                   W996[87]CF JPEG USB Dual Mode Camera Chip
-                     Driver for Linux 2.6 (basic version)
-                   =========================================
-                               - Documentation -
-Index
-=====
-1.  Copyright
-2.  Disclaimer
-3.  License
-4.  Overview
-5.  Supported devices
-6.  Module dependencies
-7.  Module loading
-8.  Module parameters
-9.  Contact information
-10. Credits
-1. Copyright
-============
-Copyright (C) 2002-2004 by Luca Risolia <luca.risolia@studio.unibo.it>
-2. Disclaimer
-=============
-Winbond is a trademark of Winbond Electronics Corporation.
-This software is not sponsored or developed by Winbond.
-3. License
-==========
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-4. Overview
-===========
-This driver supports the video streaming capabilities of the devices mounting
-Winbond W9967CF and Winbond W9968CF JPEG USB Dual Mode Camera Chips. OV681
-based cameras should be supported as well.
-The driver is divided into two modules: the basic one, "w9968cf", is needed for
-the supported devices to work; the second one, "w9968cf-vpp", is an optional
-module, which provides some useful video post-processing functions like video
-decoding, up-scaling and colour conversions.
-Note that the official kernels do neither include nor support the second
-module for performance purposes. Therefore, it is always recommended to
-download and install the latest and complete release of the driver,
-replacing the existing one, if present.
-The latest and full-featured version of the W996[87]CF driver can be found at:
-http://www.linux-projects.org. Please refer to the documentation included in
-that package, if you are going to use it.
-Up to 32 cameras can be handled at the same time. They can be connected and
-disconnected from the host many times without turning off the computer, if
-your system supports the hotplug facility.
-To change the default settings for each camera, many parameters can be passed
-through command line when the module is loaded into memory.
-The driver relies on the Video4Linux, USB and I2C core modules. It has been
-designed to run properly on SMP systems as well. An additional module,
-"ovcamchip", is mandatory; it provides support for some OmniVision image
-sensors connected to the W996[87]CF chips; if found in the system, the module
-will be automatically loaded by default (provided that the kernel has been
-compiled with the automatic module loading option).
-5. Supported devices
-====================
-At the moment, known W996[87]CF and OV681 based devices are:
- Aroma Digi Pen VGA Dual Mode ADG-5000 (unknown image sensor)
- AVerMedia AVerTV USB (SAA7111A, Philips FI1216Mk2 tuner, PT2313L audio chip)
- Creative Labs Video Blaster WebCam Go (OmniVision OV7610 sensor)
- Creative Labs Video Blaster WebCam Go Plus (OmniVision OV7620 sensor)
- Lebon LDC-035A (unknown image sensor)
- Ezonics EZ-802 EZMega Cam (OmniVision OV8610C sensor)
- OmniVision OV8610-EDE (OmniVision OV8610 sensor)
- OPCOM Digi Pen VGA Dual Mode Pen Camera (unknown image sensor)
- Pretec Digi Pen-II (OmniVision OV7620 sensor)
- Pretec DigiPen-480 (OmniVision OV8610 sensor)
-If you know any other W996[87]CF or OV681 based cameras, please contact me.
-The list above does not imply that all those devices work with this driver: up
-until now only webcams that have an image sensor supported by the "ovcamchip"
-module work. Kernel messages will always tell you whether this is case.
-Possible external microcontrollers of those webcams are not supported: this
-means that still images cannot be downloaded from the device memory.
-Furthermore, it's worth to note that I was only able to run tests on my
-"Creative Labs Video Blaster WebCam Go". Donations of other models, for
-additional testing and full support, would be much appreciated.
-6. Module dependencies
-======================
-For it to work properly, the driver needs kernel support for Video4Linux, USB
-and I2C, and the "ovcamchip" module for the image sensor. Make sure you are not
-actually using any external "ovcamchip" module, given that the W996[87]CF
-driver depends on the version of the module present in the official kernels.
-The following options of the kernel configuration file must be enabled and
-corresponding modules must be compiled:
-        # Multimedia devices
-        #
-        CONFIG_VIDEO_DEV=m
-        # I2C support
-        #
-        CONFIG_I2C=m
-The I2C core module can be compiled statically in the kernel as well.
-        # OmniVision Camera Chip support
-        #
-        CONFIG_VIDEO_OVCAMCHIP=m
-        # USB support
-        #
-        CONFIG_USB=m
-In addition, depending on the hardware being used, only one of the modules
-below is necessary:
-        # USB Host Controller Drivers
-        #
-        CONFIG_USB_EHCI_HCD=m
-        CONFIG_USB_UHCI_HCD=m
-        CONFIG_USB_OHCI_HCD=m
-And finally:
-        # USB Multimedia devices
-        #
-        CONFIG_USB_W9968CF=m
-7. Module loading
-=================
-To use the driver, it is necessary to load the "w9968cf" module into memory
-after every other module required.
-Loading can be done this way, from root:
-        [root@localhost home]# modprobe usbcore
-        [root@localhost home]# modprobe i2c-core
-        [root@localhost home]# modprobe videodev
-        [root@localhost home]# modprobe w9968cf
-At this point the pertinent devices should be recognized: "dmesg" can be used
-to analyze kernel messages:
-        [user@localhost home]$ dmesg
-There are a lot of parameters the module can use to change the default
-settings for each device. To list every possible parameter with a brief
-explanation about them and which syntax to use, it is recommended to run the
-"modinfo" command:
-        [root@locahost home]# modinfo w9968cf
-8. Module parameters
-====================
-Module parameters are listed below:
-------------------------------------------------------------------------------
-Name:            ovmod_load
-Type:            bool
-Syntax:          <0|1>
-Description:     Automatic 'ovcamchip' module loading: 0 disabled, 1 enabled.
-                 If enabled, 'insmod' searches for the required 'ovcamchip'
-                 module in the system, according to its configuration, and
-                 loads that module automatically. This action is performed as
-                 once soon as the 'w9968cf' module is loaded into memory.
-Default:         1
-------------------------------------------------------------------------------
-Name:           simcams
-Type:           int
-Syntax:         <n>
-Description:    Number of cameras allowed to stream simultaneously.
-                n may vary from 0 to 32.
-Default:        32
-------------------------------------------------------------------------------
-Name:           video_nr
-Type:           int array (min = 0, max = 32)
-Syntax:         <-1|n[,...]>
-Description:    Specify V4L minor mode number.
-                -1 = use next available
-                 n = use minor number n
-                You can specify up to 32 cameras this way.
-                For example:
-                video_nr=-1,2,-1 would assign minor number 2 to the second
-                recognized camera and use auto for the first one and for every
-                other camera.
-Default:        -1
-------------------------------------------------------------------------------
-Name:           packet_size
-Type:           int array (min = 0, max = 32)
-Syntax:         <n[,...]>
-Description:    Specify the maximum data payload size in bytes for alternate
-                settings, for each device. n is scaled between 63 and 1023.
-Default:        1023
-------------------------------------------------------------------------------
-Name:           max_buffers
-Type:           int array (min = 0, max = 32)
-Syntax:         <n[,...]>
-Description:    For advanced users.
-                Specify the maximum number of video frame buffers to allocate
-                for each device, from 2 to 32.
-Default:        2
-------------------------------------------------------------------------------
-Name:           double_buffer
-Type:           bool array (min = 0, max = 32)
-Syntax:         <0|1[,...]>
-Description:    Hardware double buffering: 0 disabled, 1 enabled.
-                It should be enabled if you want smooth video output: if you
-                obtain out of sync. video, disable it, or try to
-                decrease the 'clockdiv' module parameter value.
-Default:        1 for every device.
-------------------------------------------------------------------------------
-Name:           clamping
-Type:           bool array (min = 0, max = 32)
-Syntax:         <0|1[,...]>
-Description:    Video data clamping: 0 disabled, 1 enabled.
-Default:        0 for every device.
-------------------------------------------------------------------------------
-Name:           filter_type
-Type:           int array (min = 0, max = 32)
-Syntax:         <0|1|2[,...]>
-Description:    Video filter type.
-                0 none, 1 (1-2-1) 3-tap filter, 2 (2-3-6-3-2) 5-tap filter.
-                The filter is used to reduce noise and aliasing artifacts
-                produced by the CCD or CMOS image sensor.
-Default:        0 for every device.
-------------------------------------------------------------------------------
-Name:           largeview
-Type:           bool array (min = 0, max = 32)
-Syntax:         <0|1[,...]>
-Description:    Large view: 0 disabled, 1 enabled.
-Default:        1 for every device.
-------------------------------------------------------------------------------
-Name:           upscaling
-Type:           bool array (min = 0, max = 32)
-Syntax:         <0|1[,...]>
-Description:    Software scaling (for non-compressed video only):
-                0 disabled, 1 enabled.
-                Disable it if you have a slow CPU or you don't have enough
-                memory.
-Default:        0 for every device.
-Note:           If 'w9968cf-vpp' is not present, this parameter is set to 0.
-------------------------------------------------------------------------------
-Name:           decompression
-Type:           int array (min = 0, max = 32)
-Syntax:         <0|1|2[,...]>
-Description:    Software video decompression:
-                0 = disables decompression
-                    (doesn't allow formats needing decompression).
-                1 = forces decompression
-                    (allows formats needing decompression only).
-                2 = allows any permitted formats.
-                Formats supporting (de)compressed video are YUV422P and
-                YUV420P/YUV420 in any resolutions where width and height are
-                multiples of 16.
-Default:        2 for every device.
-Note:           If 'w9968cf-vpp' is not present, forcing decompression is not
-                allowed; in this case this parameter is set to 2.
-------------------------------------------------------------------------------
-Name:           force_palette
-Type:           int array (min = 0, max = 32)
-Syntax:         <0|9|10|13|15|8|7|1|6|3|4|5[,...]>
-Description:    Force picture palette.
-                In order:
-                 0 = Off - allows any of the following formats:
-                 9 = UYVY    16 bpp - Original video, compression disabled
-                10 = YUV420  12 bpp - Original video, compression enabled
-                13 = YUV422P 16 bpp - Original video, compression enabled
-                15 = YUV420P 12 bpp - Original video, compression enabled
-                 8 = YUVY    16 bpp - Software conversion from UYVY
-                 7 = YUV422  16 bpp - Software conversion from UYVY
-                 1 = GREY     8 bpp - Software conversion from UYVY
-                 6 = RGB555  16 bpp - Software conversion from UYVY
-                 3 = RGB565  16 bpp - Software conversion from UYVY
-                 4 = RGB24   24 bpp - Software conversion from UYVY
-                 5 = RGB32   32 bpp - Software conversion from UYVY
-                When not 0, this parameter will override 'decompression'.
-Default:        0 for every device. Initial palette is 9 (UYVY).
-Note:           If 'w9968cf-vpp' is not present, this parameter is set to 9.
-------------------------------------------------------------------------------
-Name:           force_rgb
-Type:           bool array (min = 0, max = 32)
-Syntax:         <0|1[,...]>
-Description:    Read RGB video data instead of BGR:
-                1 = use RGB component ordering.
-                0 = use BGR component ordering.
-                This parameter has effect when using RGBX palettes only.
-Default:        0 for every device.
-------------------------------------------------------------------------------
-Name:           autobright
-Type:           bool array (min = 0, max = 32)
-Syntax:         <0|1[,...]>
-Description:    Image sensor automatically changes brightness:
-                0 = no, 1 = yes
-Default:        0 for every device.
-------------------------------------------------------------------------------
-Name:           autoexp
-Type:           bool array (min = 0, max = 32)
-Syntax:         <0|1[,...]>
-Description:    Image sensor automatically changes exposure:
-                0 = no, 1 = yes
-Default:        1 for every device.
-------------------------------------------------------------------------------
-Name:           lightfreq
-Type:           int array (min = 0, max = 32)
-Syntax:         <50|60[,...]>
-Description:    Light frequency in Hz:
-                50 for European and Asian lighting, 60 for American lighting.
-Default:        50 for every device.
-------------------------------------------------------------------------------
-Name:           bandingfilter
-Type:           bool array (min = 0, max = 32)
-Syntax:         <0|1[,...]>
-Description:    Banding filter to reduce effects of fluorescent
-                lighting:
-                0 disabled, 1 enabled.
-                This filter tries to reduce the pattern of horizontal
-                light/dark bands caused by some (usually fluorescent) lighting.
-Default:        0 for every device.
-------------------------------------------------------------------------------
-Name:           clockdiv
-Type:           int array (min = 0, max = 32)
-Syntax:         <-1|n[,...]>
-Description:    Force pixel clock divisor to a specific value (for experts):
-                n may vary from 0 to 127.
-                -1 for automatic value.
-                See also the 'double_buffer' module parameter.
-Default:        -1 for every device.
-------------------------------------------------------------------------------
-Name:           backlight
-Type:           bool array (min = 0, max = 32)
-Syntax:         <0|1[,...]>
-Description:    Objects are lit from behind:
-                0 = no, 1 = yes
-Default:        0 for every device.
-------------------------------------------------------------------------------
-Name:           mirror
-Type:           bool array (min = 0, max = 32)
-Syntax:         <0|1[,...]>
-Description:    Reverse image horizontally:
-                0 = no, 1 = yes
-Default:        0 for every device.
-------------------------------------------------------------------------------
-Name:           monochrome
-Type:           bool array (min = 0, max = 32)
-Syntax:         <0|1[,...]>
-Description:    The image sensor is monochrome:
-                0 = no, 1 = yes
-Default:        0 for every device.
-------------------------------------------------------------------------------
-Name:           brightness
-Type:           long array (min = 0, max = 32)
-Syntax:         <n[,...]>
-Description:    Set picture brightness (0-65535).
-                This parameter has no effect if 'autobright' is enabled.
-Default:        31000 for every device.
-------------------------------------------------------------------------------
-Name:           hue
-Type:           long array (min = 0, max = 32)
-Syntax:         <n[,...]>
-Description:    Set picture hue (0-65535).
-Default:        32768 for every device.
-------------------------------------------------------------------------------
-Name:           colour
-Type:           long array (min = 0, max = 32)
-Syntax:         <n[,...]>
-Description:    Set picture saturation (0-65535).
-Default:        32768 for every device.
-------------------------------------------------------------------------------
-Name:           contrast
-Type:           long array (min = 0, max = 32)
-Syntax:         <n[,...]>
-Description:    Set picture contrast (0-65535).
-Default:        50000 for every device.
-------------------------------------------------------------------------------
-Name:           whiteness
-Type:           long array (min = 0, max = 32)
-Syntax:         <n[,...]>
-Description:    Set picture whiteness (0-65535).
-Default:        32768 for every device.
-------------------------------------------------------------------------------
-Name:           debug
-Type:           int
-Syntax:         <n>
-Description:    Debugging information level, from 0 to 6:
-                0 = none (use carefully)
-                1 = critical errors
-                2 = significant information
-                3 = configuration or general messages
-                4 = warnings
-                5 = called functions
-                6 = function internals
-                Level 5 and 6 are useful for testing only, when only one
-                device is used.
-Default:        2
-------------------------------------------------------------------------------
-Name:           specific_debug
-Type:           bool
-Syntax:         <0|1>
-Description:    Enable or disable specific debugging messages:
-                0 = print messages concerning every level <= 'debug' level.
-                1 = print messages concerning the level indicated by 'debug'.
-Default:        0
-------------------------------------------------------------------------------
-9. Contact information
-======================
-I may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
-I can accept GPG/PGP encrypted e-mail. My GPG key ID is 'FCE635A4'.
-My public 1024-bit key should be available at your keyserver; the fingerprint
-is: '88E8 F32F 7244 68BA 3958  5D40 99DA 5D2A FCE6 35A4'.
-10. Credits
-==========
-The development would not have proceed much further without having looked at
-the source code of other drivers and without the help of several persons; in
-particular:
- the I2C interface to kernel and high-level image sensor control routines have
-  been taken from the OV511 driver by Mark McClelland;
- memory management code has been copied from the bttv driver by Ralph Metzler,
-  Marcus Metzler and Gerd Knorr;
- the low-level I2C read function has been written by Frederic Jouault;
- the low-level I2C fast write function has been written by Piotr Czerczak.
diff --git a/Documentation/video4linux/zc0301.txt b/Documentation/video4linux/zc0301.txt
deleted file mode 100644
index b41c83cf09f4..000000000000
--- a/Documentation/video4linux/zc0301.txt
+++ /dev/null
@@ -1,270 +0,0 @@
-              ZC0301 and ZC0301P Image Processor and Control Chip
-                                Driver for Linux
-              ===================================================
-                               - Documentation -
-Index
-=====
-1.  Copyright
-2.  Disclaimer
-3.  License
-4.  Overview and features
-5.  Module dependencies
-6.  Module loading
-7.  Module parameters
-8.  Supported devices
-9.  Notes for V4L2 application developers
-10. Contact information
-11. Credits
-1. Copyright
-============
-Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it>
-2. Disclaimer
-=============
-This software is not developed or sponsored by Z-Star Microelectronics Corp.
-Trademarks are property of their respective owner.
-3. License
-==========
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-4. Overview and features
-========================
-This driver supports the video interface of the devices mounting the ZC0301 or
-ZC0301P Image Processors and Control Chips.
-The driver relies on the Video4Linux2 and USB core modules. It has been
-designed to run properly on SMP systems as well.
-The latest version of the ZC0301[P] driver can be found at the following URL:
-http://www.linux-projects.org/
-Some of the features of the driver are:
- full compliance with the Video4Linux2 API (see also "Notes for V4L2
-  application developers" paragraph);
- available mmap or read/poll methods for video streaming through isochronous
-  data transfers;
- automatic detection of image sensor;
- video format is standard JPEG;
- dynamic driver control thanks to various module parameters (see "Module
-  parameters" paragraph);
- up to 64 cameras can be handled at the same time; they can be connected and
-  disconnected from the host many times without turning off the computer, if
-  the system supports hotplugging;
-5. Module dependencies
-======================
-For it to work properly, the driver needs kernel support for Video4Linux and
-USB.
-The following options of the kernel configuration file must be enabled and
-corresponding modules must be compiled:
-        # Multimedia devices
-        #
-        CONFIG_VIDEO_DEV=m
-        # USB support
-        #
-        CONFIG_USB=m
-In addition, depending on the hardware being used, the modules below are
-necessary:
-        # USB Host Controller Drivers
-        #
-        CONFIG_USB_EHCI_HCD=m
-        CONFIG_USB_UHCI_HCD=m
-        CONFIG_USB_OHCI_HCD=m
-The ZC0301 controller also provides a built-in microphone interface. It is
-supported by the USB Audio driver thanks to the ALSA API:
-        # Sound
-        #
-        CONFIG_SOUND=y
-        # Advanced Linux Sound Architecture
-        #
-        CONFIG_SND=m
-        # USB devices
-        #
-        CONFIG_SND_USB_AUDIO=m
-And finally:
-        # V4L USB devices
-        #
-        CONFIG_USB_ZC0301=m
-6. Module loading
-=================
-To use the driver, it is necessary to load the "zc0301" module into memory
-after every other module required: "videodev", "v4l2_common", "compat_ioctl32",
-"usbcore" and, depending on the USB host controller you have, "ehci-hcd",
-"uhci-hcd" or "ohci-hcd".
-Loading can be done as shown below:
-        [root@localhost home]# modprobe zc0301
-At this point the devices should be recognized. You can invoke "dmesg" to
-analyze kernel messages and verify that the loading process has gone well:
-        [user@localhost home]$ dmesg
-7. Module parameters
-====================
-Module parameters are listed below:
-------------------------------------------------------------------------------
-Name:           video_nr
-Type:           short array (min = 0, max = 64)
-Syntax:         <-1|n[,...]>
-Description:    Specify V4L2 minor mode number:
-                -1 = use next available
-                 n = use minor number n
-                You can specify up to 64 cameras this way.
-                For example:
-                video_nr=-1,2,-1 would assign minor number 2 to the second
-                registered camera and use auto for the first one and for every
-                other camera.
-Default:        -1
-------------------------------------------------------------------------------
-Name:           force_munmap
-Type:           bool array (min = 0, max = 64)
-Syntax:         <0|1[,...]>
-Description:    Force the application to unmap previously mapped buffer memory
-                before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not
-                all the applications support this feature. This parameter is
-                specific for each detected camera.
-                0 = do not force memory unmapping
-                1 = force memory unmapping (save memory)
-Default:        0
-------------------------------------------------------------------------------
-Name:           frame_timeout
-Type:           uint array (min = 0, max = 64)
-Syntax:         <n[,...]>
-Description:    Timeout for a video frame in seconds. This parameter is
-                specific for each detected camera. This parameter can be
-                changed at runtime thanks to the /sys filesystem interface.
-Default:        2
-------------------------------------------------------------------------------
-Name:           debug
-Type:           ushort
-Syntax:         <n>
-Description:    Debugging information level, from 0 to 3:
-                0 = none (use carefully)
-                1 = critical errors
-                2 = significant information
-                3 = more verbose messages
-                Level 3 is useful for testing only, when only one device
-                is used at the same time. It also shows some information
-                about the hardware being detected. This module parameter can be
-                changed at runtime thanks to the /sys filesystem interface.
-Default:        2
-------------------------------------------------------------------------------
-8. Supported devices
-====================
-None of the names of the companies as well as their products will be mentioned
-here. They have never collaborated with the author, so no advertising.
-From the point of view of a driver, what unambiguously identify a device are
-its vendor and product USB identifiers. Below is a list of known identifiers of
-devices mounting the ZC0301 Image Processor and Control Chips:
-Vendor ID  Product ID
---------  ----------
-0x041e     0x4017
-0x041e     0x401c
-0x041e     0x401e
-0x041e     0x401f
-0x041e     0x4022
-0x041e     0x4034
-0x041e     0x4035
-0x041e     0x4036
-0x041e     0x403a
-0x0458     0x7007
-0x0458     0x700c
-0x0458     0x700f
-0x046d     0x08ae
-0x055f     0xd003
-0x055f     0xd004
-0x0ac8     0x0301
-0x0ac8     0x301b
-0x0ac8     0x303b
-0x10fd     0x0128
-0x10fd     0x8050
-0x10fd     0x804e
-The list above does not imply that all those devices work with this driver: up
-until now only the ones that mount the following image sensors are supported;
-kernel messages will always tell you whether this is the case:
-Model       Manufacturer
-----       ------------
-PAS202BCB   PixArt Imaging, Inc.
-PB-0330     Photobit Corporation
-9. Notes for V4L2 application developers
-========================================
-This driver follows the V4L2 API specifications. In particular, it enforces two
-rules:
- exactly one I/O method, either "mmap" or "read", is associated with each
-file descriptor. Once it is selected, the application must close and reopen the
-device to switch to the other I/O method;
- although it is not mandatory, previously mapped buffer memory should always
-be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's.
-The same number of buffers as before will be allocated again to match the size
-of the new video frames, so you have to map the buffers again before any I/O
-attempts on them.
-10. Contact information
-=======================
-The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
-GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is
-'FCE635A4'; the public 1024-bit key should be available at any keyserver;
-the fingerprint is: '88E8 F32F 7244 68BA 3958  5D40 99DA 5D2A FCE6 35A4'.
-11. Credits
-===========
- Information about the chip internals needed to enable the I2C protocol have
-  been taken from the documentation of the ZC030x Video4Linux1 driver written
-  by Andrew Birkett <andy@nobugs.org>;
- The initialization values of the ZC0301 controller connected to the PAS202BCB
-  and PB-0330 image sensors have been taken from the SPCA5XX driver maintained
-  by Michel Xhaard <mxhaard@magic.fr>;
- Stanislav Lechev donated one camera.
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index a4df5535996b..119358dfb742 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -219,19 +219,6 @@ allocation of vcpu ids.  For example, if userspace wants
 single-threaded guest vcpus, it should make all vcpu ids be a multiple
 of the number of vcpus per vcore.
-On powerpc using book3s_hv mode, the vcpus are mapped onto virtual
-threads in one or more virtual CPU cores.  (This is because the
-hardware requires all the hardware threads in a CPU core to be in the
-same partition.)  The KVM_CAP_PPC_SMT capability indicates the number
-of vcpus per virtual core (vcore).  The vcore id is obtained by
-dividing the vcpu id by the number of vcpus per vcore.  The vcpus in a
-given vcore will always be in the same physical core as each other
-(though that might be a different physical core from time to time).
-Userspace can control the threading (SMT) mode of the guest by its
-allocation of vcpu ids.  For example, if userspace wants
-single-threaded guest vcpus, it should make all vcpu ids be a multiple
-of the number of vcpus per vcore.
 For virtual cpus that have been created with S390 user controlled virtual
 machines, the resulting vcpu fd can be memory mapped at page offset
 KVM_S390_SIE_PAGE_OFFSET in order to obtain a memory map of the virtual
@@ -293,7 +280,7 @@ kvm_run' (see below).
 4.11 KVM_GET_REGS
 Capability: basic
-Architectures: all
+Architectures: all except ARM
 Type: vcpu ioctl
 Parameters: struct kvm_regs (out)
 Returns: 0 on success, -1 on error
@@ -314,7 +301,7 @@ struct kvm_regs {
 4.12 KVM_SET_REGS
 Capability: basic
-Architectures: all
+Architectures: all except ARM
 Type: vcpu ioctl
 Parameters: struct kvm_regs (in)
 Returns: 0 on success, -1 on error
@@ -345,7 +332,7 @@ struct kvm_sregs {
        __u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64];
 };
-/* ppc -- see arch/powerpc/include/asm/kvm.h */
+/* ppc -- see arch/powerpc/include/uapi/asm/kvm.h */
 interrupt_bitmap is a bitmap of pending external interrupts.  At most
 one bit may be set.  This interrupt has been acknowledged by the APIC
@@ -600,7 +587,7 @@ struct kvm_fpu {
 4.24 KVM_CREATE_IRQCHIP
 Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64
+Architectures: x86, ia64, ARM
 Type: vm ioctl
 Parameters: none
 Returns: 0 on success, -1 on error
@@ -608,21 +595,39 @@ Returns: 0 on success, -1 on error
 Creates an interrupt controller model in the kernel.  On x86, creates a virtual
 ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
 local APIC.  IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
-only go to the IOAPIC.  On ia64, a IOSAPIC is created.
+only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM, a GIC is
+created.
 4.25 KVM_IRQ_LINE
 Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64
+Architectures: x86, ia64, arm
 Type: vm ioctl
 Parameters: struct kvm_irq_level
 Returns: 0 on success, -1 on error
 Sets the level of a GSI input to the interrupt controller model in the kernel.
-Requires that an interrupt controller model has been previously created with
+On some architectures it is required that an interrupt controller model has
-KVM_CREATE_IRQCHIP.  Note that edge-triggered interrupts require the level
+been previously created with KVM_CREATE_IRQCHIP.  Note that edge-triggered
-to be set to 1 and then back to 0.
+interrupts require the level to be set to 1 and then back to 0.
+ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip
+(GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for
+specific cpus.  The irq field is interpreted like this:
+  bits:  | 31 ... 24 | 23  ... 16 | 15    ...    0 |
+  field: | irq_type  | vcpu_index |     irq_id     |
+The irq_type field has the following values:
+- irq_type[0]: out-of-kernel GIC: irq_id 0 is IRQ, irq_id 1 is FIQ
+- irq_type[1]: in-kernel GIC: SPI, irq_id between 32 and 1019 (incl.)
+               (the vcpu_index field is ignored)
+- irq_type[2]: in-kernel GIC: PPI, irq_id between 16 and 31 (incl.)
+(The irq_id field thus corresponds nicely to the IRQ ID in the ARM GIC specs)
+In both cases, level is used to raise/lower the line.
 struct kvm_irq_level {
        union {
@@ -874,12 +879,12 @@ It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr
 be identical.  This allows large pages in the guest to be backed by large
 pages in the host.
-The flags field supports two flag, KVM_MEM_LOG_DIRTY_PAGES, which instructs
+The flags field supports two flags: KVM_MEM_LOG_DIRTY_PAGES and
-kvm to keep track of writes to memory within the slot.  See KVM_GET_DIRTY_LOG
+KVM_MEM_READONLY.  The former can be set to instruct KVM to keep track of
-ioctl.  The KVM_CAP_READONLY_MEM capability indicates the availability of the
+writes to memory within the slot.  See KVM_GET_DIRTY_LOG ioctl to know how to
-KVM_MEM_READONLY flag.  When this flag is set for a memory region, KVM only
+use it.  The latter can be set, if KVM_CAP_READONLY_MEM capability allows it,
-allows read accesses.  Writes will be posted to userspace as KVM_EXIT_MMIO
+to make a new slot read-only.  In this case, writes to this memory will be
-exits.
+posted to userspace as KVM_EXIT_MMIO exits.
 When the KVM_CAP_SYNC_MMU capability is available, changes in the backing of
 the memory region are automatically reflected into the guest.  For example, an
@@ -913,7 +918,7 @@ documentation when it pops into existence).
 4.37 KVM_ENABLE_CAP
 Capability: KVM_CAP_ENABLE_CAP
-Architectures: ppc
+Architectures: ppc, s390
 Type: vcpu ioctl
 Parameters: struct kvm_enable_cap (in)
 Returns: 0 on success; -1 on error
@@ -1774,6 +1779,28 @@ registers, find a list below:
  PPC   | KVM_REG_PPC_VPA_SLB   | 128
  PPC   | KVM_REG_PPC_VPA_DTL   | 128
  PPC   | KVM_REG_PPC_EPCR      | 32
+  PPC   | KVM_REG_PPC_EPR       | 32
+ARM registers are mapped using the lower 32 bits.  The upper 16 of that
+is the register group type, or coprocessor number:
+ARM core registers have the following id bit patterns:
+  0x4002 0000 0010 <index into the kvm_regs struct:16>
+ARM 32-bit CP15 registers have the following id bit patterns:
+  0x4002 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
+ARM 64-bit CP15 registers have the following id bit patterns:
+  0x4003 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
+ARM CCSIDR registers are demultiplexed by CSSELR value:
+  0x4002 0000 0011 00 <csselr:8>
+ARM 32-bit VFP control registers have the following id bit patterns:
+  0x4002 0000 0012 1 <regno:12>
+ARM 64-bit FP registers have the following id bit patterns:
+  0x4002 0000 0012 0 <regno:12>
 4.69 KVM_GET_ONE_REG
@@ -2069,6 +2096,14 @@ KVM_S390_INT_VIRTIO (vm) - virtio external interrupt; external interrupt
 KVM_S390_INT_SERVICE (vm) - sclp external interrupt; sclp parameter in parm
 KVM_S390_INT_EMERGENCY (vcpu) - sigp emergency; source cpu in parm
 KVM_S390_INT_EXTERNAL_CALL (vcpu) - sigp external call; source cpu in parm
+KVM_S390_INT_IO(ai,cssid,ssid,schid) (vm) - compound value to indicate an
+    I/O interrupt (ai - adapter interrupt; cssid,ssid,schid - subchannel);
+    I/O interruption parameters in parm (subchannel) and parm64 (intparm,
+    interruption subclass)
+KVM_S390_MCHK (vm, vcpu) - machine check interrupt; cr 14 bits in parm,
+                           machine check interrupt code in parm64 (note that
+                           machine checks needing further payload are not
+                           supported by this ioctl)
 Note that the vcpu ioctl is asynchronous to vcpu execution.
@@ -2127,6 +2162,88 @@ written, then `n_invalid' invalid entries, invalidating any previously
 valid entries found.
+4.77 KVM_ARM_VCPU_INIT
+Capability: basic
+Architectures: arm
+Type: vcpu ioctl
+Parameters: struct struct kvm_vcpu_init (in)
+Returns: 0 on success; -1 on error
+Errors:
+  EINVAL:    the target is unknown, or the combination of features is invalid.
+  ENOENT:    a features bit specified is unknown.
+This tells KVM what type of CPU to present to the guest, and what
+optional features it should have.  This will cause a reset of the cpu
+registers to their initial values.  If this is not called, KVM_RUN will
+return ENOEXEC for that vcpu.
+Note that because some registers reflect machine topology, all vcpus
+should be created before this ioctl is invoked.
+Possible features:
+        - KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state.
+          Depends on KVM_CAP_ARM_PSCI.
+4.78 KVM_GET_REG_LIST
+Capability: basic
+Architectures: arm
+Type: vcpu ioctl
+Parameters: struct kvm_reg_list (in/out)
+Returns: 0 on success; -1 on error
+Errors:
+  E2BIG:     the reg index list is too big to fit in the array specified by
+             the user (the number required will be written into n).
+struct kvm_reg_list {
+        __u64 n; /* number of registers in reg[] */
+        __u64 reg[0];
+};
+This ioctl returns the guest registers that are supported for the
+KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
+4.80 KVM_ARM_SET_DEVICE_ADDR
+Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
+Architectures: arm
+Type: vm ioctl
+Parameters: struct kvm_arm_device_address (in)
+Returns: 0 on success, -1 on error
+Errors:
+  ENODEV: The device id is unknown
+  ENXIO:  Device not supported on current system
+  EEXIST: Address already set
+  E2BIG:  Address outside guest physical address space
+  EBUSY:  Address overlaps with other device range
+struct kvm_arm_device_addr {
+        __u64 id;
+        __u64 addr;
+};
+Specify a device address in the guest's physical address space where guests
+can access emulated or directly exposed devices, which the host kernel needs
+to know about. The id field is an architecture specific identifier for a
+specific device.
+ARM divides the id field into two parts, a device id and an address type id
+specific to the individual device.
+  bits:  | 63        ...       32 | 31    ...    16 | 15    ...    0 |
+  field: |        0x00000000      |     device id   |  addr type id  |
+ARM currently only require this when using the in-kernel GIC support for the
+hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2 as the device id.  When
+setting the base address for the guest's mapping of the VGIC virtual CPU
+and distributor interface, the ioctl must be called after calling
+KVM_CREATE_IRQCHIP, but before calling KVM_RUN on any of the VCPUs.  Calling
+this ioctl twice for any of the base addresses will return -EEXIST.
 5. The kvm_run structure
 ------------------------
@@ -2238,8 +2355,8 @@ executed a memory-mapped I/O instruction which could not be satisfied
 by kvm.  The 'data' member contains the written data if 'is_write' is
 true, and should be filled by application code otherwise.
-NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_DCR
+NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_DCR,
-      and KVM_EXIT_PAPR the corresponding
+      KVM_EXIT_PAPR and KVM_EXIT_EPR the corresponding
 operations are complete (and guest state is consistent) only after userspace
 has re-entered the kernel with KVM_RUN.  The kernel side will first finish
 incomplete operations and then check for pending signals.  Userspace
@@ -2342,6 +2459,41 @@ The possible hypercalls are defined in the Power Architecture Platform
 Requirements (PAPR) document available from www.power.org (free
 developer registration required to access it).
+                /* KVM_EXIT_S390_TSCH */
+                struct {
+                        __u16 subchannel_id;
+                        __u16 subchannel_nr;
+                        __u32 io_int_parm;
+                        __u32 io_int_word;
+                        __u32 ipb;
+                        __u8 dequeued;
+                } s390_tsch;
+s390 specific. This exit occurs when KVM_CAP_S390_CSS_SUPPORT has been enabled
+and TEST SUBCHANNEL was intercepted. If dequeued is set, a pending I/O
+interrupt for the target subchannel has been dequeued and subchannel_id,
+subchannel_nr, io_int_parm and io_int_word contain the parameters for that
+interrupt. ipb is needed for instruction parameter decoding.
+                /* KVM_EXIT_EPR */
+                struct {
+                        __u32 epr;
+                } epr;
+On FSL BookE PowerPC chips, the interrupt controller has a fast patch
+interrupt acknowledge path to the core. When the core successfully
+delivers an interrupt, it automatically populates the EPR register with
+the interrupt vector number and acknowledges the interrupt inside
+the interrupt controller.
+In case the interrupt controller lives in user space, we need to do
+the interrupt acknowledge cycle through it to fetch the next to be
+delivered interrupt vector using this exit.
+It gets triggered whenever both KVM_CAP_PPC_EPR are enabled and an
+external interrupt has just been delivered into the guest. User space
+should put the acknowledged interrupt vector into the 'epr' field.
                /* Fix the size of the union. */
                char padding[256];
        };
@@ -2463,3 +2615,34 @@ For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV:
   where "num_sets" is the tlb_sizes[] value divided by the tlb_ways[] value.
 - The tsize field of mas1 shall be set to 4K on TLB0, even though the
   hardware ignores this value for TLB0.
+6.4 KVM_CAP_S390_CSS_SUPPORT
+Architectures: s390
+Parameters: none
+Returns: 0 on success; -1 on error
+This capability enables support for handling of channel I/O instructions.
+TEST PENDING INTERRUPTION and the interrupt portion of TEST SUBCHANNEL are
+handled in-kernel, while the other I/O instructions are passed to userspace.
+When this capability is enabled, KVM_EXIT_S390_TSCH will occur on TEST
+SUBCHANNEL intercepts.
+6.5 KVM_CAP_PPC_EPR
+Architectures: ppc
+Parameters: args[0] defines whether the proxy facility is active
+Returns: 0 on success; -1 on error
+This capability enables or disables the delivery of interrupts through the
+external proxy facility.
+When enabled (args[0] != 0), every time the guest gets an external interrupt
+delivered, it automatically exits into user space with a KVM_EXIT_EPR exit
+to receive the topmost interrupt vector.
+When disabled (args[0] == 0), behavior is as if this facility is unsupported.
+When this capability is enabled, KVM_EXIT_EPR can occur.
diff --git a/Documentation/virtual/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt
index fa5f1dbc6b23..43fcb761ed16 100644
--- a/Documentation/virtual/kvm/mmu.txt
+++ b/Documentation/virtual/kvm/mmu.txt
@@ -187,13 +187,6 @@ Shadow pages contain the following information:
    perform a reverse map from a pte to a gfn. When role.direct is set, any
    element of this array can be calculated from the gfn field when used, in
    this case, the array of gfns is not allocated. See role.direct and gfn.
-  slot_bitmap:
-    A bitmap containing one bit per memory slot.  If the page contains a pte
-    mapping a page from memory slot n, then bit n of slot_bitmap will be set
-    (if a page is aliased among several slots, then it is not guaranteed that
-    all slots will be marked).
-    Used during dirty logging to avoid scanning a shadow page if none if its
-    pages need tracking.
  root_count:
    A counter keeping track of how many hardware registers (guest cr3 or
    pdptrs) are now pointing at the page.  While this counter is nonzero, the
diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt
index b392e496f816..f34a8ee6f860 100644
--- a/Documentation/vm/ksm.txt
+++ b/Documentation/vm/ksm.txt
@@ -58,6 +58,21 @@ sleep_millisecs  - how many milliseconds ksmd should sleep before next scan
                   e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
                   Default: 20 (chosen for demonstration purposes)
+merge_across_nodes - specifies if pages from different numa nodes can be merged.
+                   When set to 0, ksm merges only pages which physically
+                   reside in the memory area of same NUMA node. That brings
+                   lower latency to access of shared pages. Systems with more
+                   nodes, at significant NUMA distances, are likely to benefit
+                   from the lower latency of setting 0. Smaller systems, which
+                   need to minimize memory usage, are likely to benefit from
+                   the greater sharing of setting 1 (default). You may wish to
+                   compare how your system performs under each setting, before
+                   deciding on which to use. merge_across_nodes setting can be
+                   changed only when there are no ksm shared pages in system:
+                   set run 2 to unmerge pages first, then to 1 after changing
+                   merge_across_nodes, to remerge according to the new setting.
+                   Default: 1 (merging across nodes as in earlier releases)
 run              - set 0 to stop ksmd from running but keep merged pages,
                   set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
                   set 2 to stop ksmd and unmerge all pages currently merged,
diff --git a/Documentation/w1/slaves/w1_therm b/Documentation/w1/slaves/w1_therm
index 874a8ca93feb..cc62a95e4776 100644
--- a/Documentation/w1/slaves/w1_therm
+++ b/Documentation/w1/slaves/w1_therm
@@ -34,9 +34,16 @@ currently supported.  The driver also doesn't support reduced
 precision (which would also reduce the conversion time).
 The module parameter strong_pullup can be set to 0 to disable the
-strong pullup or 1 to enable.  If enabled the 5V strong pullup will be
+strong pullup, 1 to enable autodetection or 2 to force strong pullup.
-enabled when the conversion is taking place provided the master driver
+In case of autodetection, the driver will use the "READ POWER SUPPLY"
-must support the strong pullup (or it falls back to a pullup
+command to check if there are pariste powered devices on the bus.
+If so, it will activate the master's strong pullup.
+In case the detection of parasite devices using this command fails
+(seems to be the case with some DS18S20) the strong pullup can
+be force-enabled.
+If the strong pullup is enabled, the master's strong pullup will be
+driven when the conversion is taking place, provided the master driver
+does support the strong pullup (or it falls back to a pullup
 resistor).  The DS18b20 temperature sensor specification lists a
 maximum current draw of 1.5mA and that a 5k pullup resistor is not
 sufficient.  The strong pullup is designed to provide the additional
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 406d82d5d2bb..3840b6f28afb 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -57,6 +57,10 @@ Protocol 2.10:	(Kernel 2.6.31) Added a protocol for relaxed alignment
 Protocol 2.11:  (Kernel 3.6) Added a field for offset of EFI handover
                protocol entry point.
+Protocol 2.12:  (Kernel 3.8) Added the xloadflags field and extension fields
+                to struct boot_params for for loading bzImage and ramdisk
+                above 4G in 64bit.
 **** MEMORY LAYOUT
 The traditional memory map for the kernel loader, used for Image or
@@ -182,7 +186,7 @@ Offset	Proto	Name		Meaning
 0230/4  2.05+   kernel_alignment Physical addr alignment required for kernel
 0234/1  2.05+   relocatable_kernel Whether kernel is relocatable or not
 0235/1  2.10+   min_alignment   Minimum alignment, as a power of two
-0236/2  N/A     pad3            Unused
+0236/2  2.12+   xloadflags      Boot protocol option flags
 0238/4  2.06+   cmdline_size    Maximum size of the kernel command line
 023C/4  2.07+   hardware_subarch Hardware subarchitecture
 0240/8  2.07+   hardware_subarch_data Subarchitecture-specific data
@@ -386,6 +390,7 @@ Protocol:	2.00+
        F  Special              (0xFF = undefined)
       10  Reserved
       11  Minimal Linux Bootloader <http://sebastian-plotz.blogspot.de>
+       12  OVMF UEFI virtualization stack
  Please contact <hpa@zytor.com> if you need a bootloader ID
  value assigned.
@@ -582,6 +587,27 @@ Protocol:	2.10+
  misaligned kernel.  Therefore, a loader should typically try each
  power-of-two alignment from kernel_alignment down to this alignment.
+Field name:     xloadflags
+Type:           read
+Offset/size:    0x236/2
+Protocol:       2.12+
+  This field is a bitmask.
+  Bit 0 (read): XLF_KERNEL_64
+        - If 1, this kernel has the legacy 64-bit entry point at 0x200.
+  Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
+        - If 1, kernel/boot_params/cmdline/ramdisk can be above 4G.
+  Bit 2 (read): XLF_EFI_HANDOVER_32
+        - If 1, the kernel supports the 32-bit EFI handoff entry point
+          given at handover_offset.
+  Bit 3 (read): XLF_EFI_HANDOVER_64
+        - If 1, the kernel supports the 64-bit EFI handoff entry point
+          given at handover_offset + 0x200.
 Field name:     cmdline_size
 Type:           read
 Offset/size:    0x238/4
@@ -1029,6 +1055,44 @@ must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
 must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
 address of the struct boot_params; %ebp, %edi and %ebx must be zero.
+**** 64-bit BOOT PROTOCOL
+For machine with 64bit cpus and 64bit kernel, we could use 64bit bootloader
+and we need a 64-bit boot protocol.
+In 64-bit boot protocol, the first step in loading a Linux kernel
+should be to setup the boot parameters (struct boot_params,
+traditionally known as "zero page"). The memory for struct boot_params
+could be allocated anywhere (even above 4G) and initialized to all zero.
+Then, the setup header at offset 0x01f1 of kernel image on should be
+loaded into struct boot_params and examined. The end of setup header
+can be calculated as follows:
+        0x0202 + byte value at offset 0x0201
+In addition to read/modify/write the setup header of the struct
+boot_params as that of 16-bit boot protocol, the boot loader should
+also fill the additional fields of the struct boot_params as described
+in zero-page.txt.
+After setting up the struct boot_params, the boot loader can load
+64-bit kernel in the same way as that of 16-bit boot protocol, but
+kernel could be loaded above 4G.
+In 64-bit boot protocol, the kernel is started by jumping to the
+64-bit kernel entry point, which is the start address of loaded
+64-bit kernel plus 0x200.
+At entry, the CPU must be in 64-bit mode with paging enabled.
+The range with setup_header.init_size from start address of loaded
+kernel and zero page and command line buffer get ident mapping;
+a GDT must be loaded with the descriptors for selectors
+__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
+segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
+must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
+must be __BOOT_DS; interrupt must be disabled; %rsi must hold the base
+address of the struct boot_params.
 **** EFI HANDOVER PROTOCOL
 This protocol allows boot loaders to defer initialisation to the EFI
diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt
new file mode 100644
index 000000000000..4aaf0dfb0cb8
--- /dev/null
+++ b/Documentation/x86/early-microcode.txt
@@ -0,0 +1,43 @@
+Early load microcode
+====================
+By Fenghua Yu <fenghua.yu@intel.com>
+Kernel can update microcode in early phase of boot time. Loading microcode early
+can fix CPU issues before they are observed during kernel boot time.
+Microcode is stored in an initrd file. The microcode is read from the initrd
+file and loaded to CPUs during boot time.
+The format of the combined initrd image is microcode in cpio format followed by
+the initrd image (maybe compressed). Kernel parses the combined initrd image
+during boot time. The microcode file in cpio name space is:
+kernel/x86/microcode/GenuineIntel.bin
+During BSP boot (before SMP starts), if the kernel finds the microcode file in
+the initrd file, it parses the microcode and saves matching microcode in memory.
+If matching microcode is found, it will be uploaded in BSP and later on in all
+APs.
+The cached microcode patch is applied when CPUs resume from a sleep state.
+There are two legacy user space interfaces to load microcode, either through
+/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file
+in sysfs.
+In addition to these two legacy methods, the early loading method described
+here is the third method with which microcode can be uploaded to a system's
+CPUs.
+The following example script shows how to generate a new combined initrd file in
+/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and
+original initrd image /boot/initrd-3.5.0.img.
+mkdir initrd
+cd initrd
+mkdir kernel
+mkdir kernel/x86
+mkdir kernel/x86/microcode
+cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin
+find .|cpio -oc >../ucode.cpio
+cd ..
+cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img
diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt
index de38429beb71..e015a83c3996 100644
--- a/Documentation/x86/x86_64/boot-options.txt
+++ b/Documentation/x86/x86_64/boot-options.txt
@@ -112,10 +112,6 @@ Timing
  This can be used to work around timing problems on multiprocessor systems
  with not properly synchronized CPUs.
-  report_lost_ticks
-  Report when timer interrupts are lost because some code turned off
-  interrupts for too long.
  nohpet
  Don't use the HPET timer.
diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index cf5437deda81..199f453cb4de 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -19,6 +19,9 @@ Offset	Proto	Name		Meaning
 090/010 ALL     hd1_info        hd1 disk parameter, OBSOLETE!!
 0A0/010 ALL     sys_desc_table  System description table (struct sys_desc_table)
 0B0/010 ALL     olpc_ofw_header OLPC's OpenFirmware CIF and friends
+0C0/004 ALL     ext_ramdisk_image ramdisk_image high 32bits
+0C4/004 ALL     ext_ramdisk_size  ramdisk_size high 32bits
+0C8/004 ALL     ext_cmd_line_ptr  cmd_line_ptr high 32bits
 140/080 ALL     edid_info       Video mode setup (struct edid_info)
 1C0/020 ALL     efi_info        EFI 32 information (struct efi_info)
 1E0/004 ALL     alk_mem_k       Alternative mem check, in KB
@@ -27,6 +30,7 @@ Offset	Proto	Name		Meaning
 1E9/001 ALL     eddbuf_entries  Number of entries in eddbuf (below)
 1EA/001 ALL     edd_mbr_sig_buf_entries Number of entries in edd_mbr_sig_buffer
                                (below)
+1EF/001 ALL     sentinel        Used to detect broken bootloaders
 290/040 ALL     edd_mbr_sig_buffer EDD MBR signatures
 2D0/A00 ALL     e820_map        E820 memory map table
                                (array of struct e820entry)
diff --git a/Documentation/zh_CN/CodingStyle b/Documentation/zh_CN/CodingStyle
index ecd9307a641f..654afd72eb24 100644
--- a/Documentation/zh_CN/CodingStyle
+++ b/Documentation/zh_CN/CodingStyle
@@ -462,13 +462,6 @@ config AUDIT
          logging of avc messages output).  Does not do system-call
          auditing without CONFIG_AUDITSYSCALL.
-仍然被认为不够稳定的功能应该被定义为依赖于“EXPERIMENTAL”：
-config SLUB
-        depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT
-        bool "SLUB (Unqueued Allocator)"
-        ...
 而那些危险的功能（比如某些文件系统的写支持）应该在它们的提示字符串里显著的声明这
 一点：
diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt
index 4263022f5002..2ebe539f5450 100644
--- a/Documentation/zh_CN/magic-number.txt
+++ b/Documentation/zh_CN/magic-number.txt
@@ -122,7 +122,7 @@ SLAB_C_MAGIC          0x4f17a36d  kmem_cache        mm/slab.c
 COW_MAGIC             0x4f4f4f4d  cow_header_v1     arch/um/drivers/ubd_user.c
 I810_CARD_MAGIC       0x5072696E  i810_card         sound/oss/i810_audio.c
 TRIDENT_CARD_MAGIC    0x5072696E  trident_card      sound/oss/trident.c
-ROUTER_MAGIC          0x524d4157  wan_device        include/linux/wanrouter.h
+ROUTER_MAGIC          0x524d4157  wan_device        [in wanrouter.h pre 3.9]
 SCC_MAGIC             0x52696368  gs_port           drivers/char/scc.h
 SAVEKMSG_MAGIC1       0x53415645  savekmsg          arch/*/amiga/config.c
 GDA_MAGIC             0x58464552  gda               arch/mips/include/asm/sn/gda.h