Merge tag 'v3.9-rc3' into next

Merge with mainline to bring in module_platform_driver_probe() and devm_ioremap_resource().
2013-03-17 19:40:50 -07:00
parent 1614265526 a937536b86
commit 688d794c4c
17348 changed files with 1083156 additions and 593704 deletions
--- a/.gitignore
+++ b/.gitignore
@@ -60,7 +60,6 @@ modules.builtin
 # Generated include files
 #
 include/config
 include/linux/version.h
 include/generated
 arch/*/include/generated
--- a/19
+++ b/19
@@ -953,11 +953,11 @@ S: Blacksburg, Virginia 24061
 S: USA
 N: Randy Dunlap
-E: rdunlap@xenotime.net
+E: rdunlap@infradead.org
-W: http://www.xenotime.net/linux/linux.html
+W: http://www.infradead.org/~rdunlap/
 W: http://www.linux-usb.org
 D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
 D: x86 SMP, ACPI, bootflag hacking
 D: documentation, builds
 S: (ask for current address)
 S: USA
@@ -1572,12 +1572,12 @@ S: Wantage, New Jersey 07461
 S: USA
 N: Harald Hoyer
-E: harald.hoyer@parzelle.de
+E: harald@redhat.com
-W: http://parzelle.de/
+W: http://www.harald-hoyer.de
 D: ip_masq_quake
 D: md boot support
-S: Hohe Strasse 30
+S: Am Strand 5
-S: D-70176 Stuttgart
+S: D-19063 Schwerin
 S: Germany
 N: Jan Hubicka
@@ -1823,6 +1823,11 @@ S: Kattreinstr 38
 S: D-64295
 S: Germany
 N: Avi Kivity
 E: avi.kivity@gmail.com
 D: Kernel-based Virtual Machine (KVM)
 S: Ra'annana, Israel
 N: Andi Kleen
 E: andi@firstfloor.org
 U: http://www.halobates.de
--- 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,40 +141,66 @@ 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/
 	- directory with info on the frame buffer graphics abstraction layer.
 feature-removal-schedule.txt
 	- list of files and features that are going to be removed.
 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
@@ -164,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
@@ -184,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/
@@ -194,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
@@ -210,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
@@ -222,16 +289,28 @@ 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.
 metag/
 	- directory with info about Linux on Meta architecture.
 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
@@ -242,6 +321,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
@@ -258,26 +339,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
@@ -302,10 +403,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/
@@ -316,6 +417,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
@@ -324,27 +427,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.
--- a/Documentation/ABI/README
+++ b/Documentation/ABI/README
@@ -36,9 +36,6 @@ The different levels of stability are:
 	the kernel, but are marked to be removed at some later point in
 	time.  The description of the interface will document the reason
 	why it is obsolete and when it can be expected to be removed.
 	The file Documentation/feature-removal-schedule.txt may describe
 	some of these interfaces, giving a schedule for when they will
 	be removed.
  removed/
 	This directory contains a list of the old interfaces that have
--- a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus
+++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus
@@ -8,3 +8,41 @@ Description:	The integer value of this attribute ranges from 0-4.
 		When written, this file sets the number of the startup profile
 		and the mouse activates this profile immediately.
 		Please use actual_profile, it does the same thing.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version
 Date:		October 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	When read, this file returns the raw integer version number of the
 		firmware reported by the mouse. Using the integer value eases
 		further usage in other programs. To receive the real version
 		number the decimal point has to be shifted 2 positions to the
 		left. E.g. a returned value of 121 means 1.21
 		This file is readonly.
 		Please read binary attribute info which contains firmware version.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_buttons holds information about button layout.
 		When read, these files return the respective profile buttons.
 		The returned data is 77 bytes in size.
 		This file is readonly.
 		Write control to select profile and read profile_buttons instead.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_settings holds information like resolution, sensitivity
 		and light effects.
 		When read, these files return the respective profile settings.
 		The returned data is 43 bytes in size.
 		This file is readonly.
 		Write control to select profile and read profile_settings instead.
 Users:		http://roccat.sourceforge.net
--- a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus
+++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus
@@ -0,0 +1,66 @@
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_cpi
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The integer value of this attribute ranges from 1-4.
 		When read, this attribute returns the number of the active
 		cpi level.
 		This file is readonly.
 		Has never been used. If bookkeeping is done, it's done in userland tools.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_x
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The integer value of this attribute ranges from 1-10.
 		When read, this attribute returns the number of the actual
 		sensitivity in x direction.
 		This file is readonly.
 		Has never been used. If bookkeeping is done, it's done in userland tools.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_y
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The integer value of this attribute ranges from 1-10.
 		When read, this attribute returns the number of the actual
 		sensitivity in y direction.
 		This file is readonly.
 		Has never been used. If bookkeeping is done, it's done in userland tools.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/firmware_version
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	When read, this file returns the raw integer version number of the
 		firmware reported by the mouse. Using the integer value eases
 		further usage in other programs. To receive the real version
 		number the decimal point has to be shifted 2 positions to the
 		left. E.g. a returned value of 121 means 1.21
 		This file is readonly.
 		Obsoleted by binary sysfs attribute "info".
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_buttons
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_buttons holds information about button layout.
 		When read, these files return the respective profile buttons.
 		The returned data is 23 bytes in size.
 		This file is readonly.
 		Write control to select profile and read profile_buttons instead.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_settings
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_settings holds information like resolution, sensitivity
 		and light effects.
 		When read, these files return the respective profile settings.
 		The returned data is 16 bytes in size.
 		This file is readonly.
 		Write control to select profile and read profile_settings instead.
 Users:		http://roccat.sourceforge.net
--- a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra
+++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra
@@ -0,0 +1,73 @@
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_cpi
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	It is possible to switch the cpi setting of the mouse with the
 		press of a button.
 		When read, this file returns the raw number of the actual cpi
 		setting reported by the mouse. This number has to be further
 		processed to receive the real dpi value.
 		VALUE DPI
 		1     400
 		2     800
 		4     1600
 		This file is readonly.
 		Has never been used. If bookkeeping is done, it's done in userland tools.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	When read, this file returns the number of the actual profile in
 		range 0-4.
 		This file is readonly.
 		Please use binary attribute "settings" which provides this information.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	When read, this file returns the raw integer version number of the
 		firmware reported by the mouse. Using the integer value eases
 		further usage in other programs. To receive the real version
 		number the decimal point has to be shifted 2 positions to the
 		left. E.g. a returned value of 138 means 1.38
 		This file is readonly.
 		Please use binary attribute "info" which provides this information.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_buttons
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_buttons holds information about button layout.
 		When read, these files return the respective profile buttons.
 		The returned data is 19 bytes in size.
 		This file is readonly.
 		Write control to select profile and read profile_buttons instead.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_settings
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_settings holds information like resolution, sensitivity
 		and light effects.
 		When read, these files return the respective profile settings.
 		The returned data is 13 bytes in size.
 		This file is readonly.
 		Write control to select profile and read profile_settings instead.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The integer value of this attribute ranges from 0-4.
                When read, this attribute returns the number of the profile
                that's active when the mouse is powered on.
 		This file is readonly.
 		Please use binary attribute "settings" which provides this information.
 Users:		http://roccat.sourceforge.net
--- a/Documentation/ABI/stable/sysfs-class-tpm
+++ 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.
--- a/Documentation/ABI/stable/sysfs-devices-node
+++ b/Documentation/ABI/stable/sysfs-devices-node
@@ -1,7 +1,101 @@
 What:		/sys/devices/system/node/possible
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		Nodes that could be possibly become online at some point.
 What:		/sys/devices/system/node/online
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		Nodes that are online.
 What:		/sys/devices/system/node/has_normal_memory
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		Nodes that have regular memory.
 What:		/sys/devices/system/node/has_cpu
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		Nodes that have one or more CPUs.
 What:		/sys/devices/system/node/has_high_memory
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		Nodes that have regular or high memory.
 		Depends on CONFIG_HIGHMEM.
 What:		/sys/devices/system/node/nodeX
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		When CONFIG_NUMA is enabled, this is a directory containing
 		information on node X such as what CPUs are local to the
-		node.
+		node. Each file is detailed next.
 What:		/sys/devices/system/node/nodeX/cpumap
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		The node's cpumap.
 What:		/sys/devices/system/node/nodeX/cpulist
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		The CPUs associated to the node.
 What:		/sys/devices/system/node/nodeX/meminfo
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		Provides information about the node's distribution and memory
 		utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.txt
 What:		/sys/devices/system/node/nodeX/numastat
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		The node's hit/miss statistics, in units of pages.
 		See Documentation/numastat.txt
 What:		/sys/devices/system/node/nodeX/distance
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		Distance between the node and all the other nodes
 		in the system.
 What:		/sys/devices/system/node/nodeX/vmstat
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
 Description:
 		The node's zoned virtual memory statistics.
 		This is a superset of numastat.
 What:		/sys/devices/system/node/nodeX/compact
 Date:		February 2010
 Contact:	Mel Gorman <mel@csn.ul.ie>
 Description:
 		When this file is written to, all memory within that node
 		will be compacted. When it completes, memory will be freed
 		into blocks which have as many contiguous pages as possible
 What:		/sys/devices/system/node/nodeX/scan_unevictable_pages
 Date:		October 2008
 Contact:	Lee Schermerhorn <lee.schermerhorn@hp.com>
 Description:
 		When set, it triggers scanning the node's unevictable lists
 		and move any pages that have become evictable onto the respective
 		zone's inactive list. See mm/vmscan.c
 What:		/sys/devices/system/node/nodeX/hugepages/hugepages-<size>/
 Date:		December 2009
 Contact:	Lee Schermerhorn <lee.schermerhorn@hp.com>
 Description:
 		The node's huge page size control/query attributes.
 		See Documentation/vm/hugetlbpage.txt
--- a/Documentation/ABI/stable/sysfs-driver-ib_srp
+++ b/Documentation/ABI/stable/sysfs-driver-ib_srp
@@ -0,0 +1,156 @@
 What:		/sys/class/infiniband_srp/srp-<hca>-<port_number>/add_target
 Date:		January 2, 2006
 KernelVersion:	2.6.15
 Contact:	linux-rdma@vger.kernel.org
 Description:	Interface for making ib_srp connect to a new target.
 		One can request ib_srp to connect to a new target by writing
 		a comma-separated list of login parameters to this sysfs
 		attribute. The supported parameters are:
 		* id_ext, a 16-digit hexadecimal number specifying the eight
 		  byte identifier extension in the 16-byte SRP target port
 		  identifier. The target port identifier is sent by ib_srp
 		  to the target in the SRP_LOGIN_REQ request.
 		* ioc_guid, a 16-digit hexadecimal number specifying the eight
 		  byte I/O controller GUID portion of the 16-byte target port
 		  identifier.
 		* dgid, a 32-digit hexadecimal number specifying the
 		  destination GID.
 		* pkey, a four-digit hexadecimal number specifying the
 		  InfiniBand partition key.
 		* service_id, a 16-digit hexadecimal number specifying the
 		  InfiniBand service ID used to establish communication with
 		  the SRP target. How to find out the value of the service ID
 		  is specified in the documentation of the SRP target.
 		* max_sect, a decimal number specifying the maximum number of
 		  512-byte sectors to be transferred via a single SCSI command.
 		* max_cmd_per_lun, a decimal number specifying the maximum
 		  number of outstanding commands for a single LUN.
 		* io_class, a hexadecimal number specifying the SRP I/O class.
 		  Must be either 0xff00 (rev 10) or 0x0100 (rev 16a). The I/O
 		  class defines the format of the SRP initiator and target
 		  port identifiers.
 		* initiator_ext, a 16-digit hexadecimal number specifying the
 		  identifier extension portion of the SRP initiator port
 		  identifier. This data is sent by the initiator to the target
 		  in the SRP_LOGIN_REQ request.
 		* cmd_sg_entries, a number in the range 1..255 that specifies
 		  the maximum number of data buffer descriptors stored in the
 		  SRP_CMD information unit itself. With allow_ext_sg=0 the
 		  parameter cmd_sg_entries defines the maximum S/G list length
 		  for a single SRP_CMD, and commands whose S/G list length
 		  exceeds this limit after S/G list collapsing will fail.
 		* allow_ext_sg, whether ib_srp is allowed to include a partial
 		  memory descriptor list in an SRP_CMD instead of the entire
 		  list. If a partial memory descriptor list has been included
 		  in an SRP_CMD the remaining memory descriptors are
 		  communicated from initiator to target via an additional RDMA
 		  transfer. Setting allow_ext_sg to 1 increases the maximum
 		  amount of data that can be transferred between initiator and
 		  target via a single SCSI command. Since not all SRP target
 		  implementations support partial memory descriptor lists the
 		  default value for this option is 0.
 		* sg_tablesize, a number in the range 1..2048 specifying the
 		  maximum S/G list length the SCSI layer is allowed to pass to
 		  ib_srp. Specifying a value that exceeds cmd_sg_entries is
 		  only safe with partial memory descriptor list support enabled
 		  (allow_ext_sg=1).
 What:		/sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
 Date:		January 2, 2006
 KernelVersion:	2.6.15
 Contact:	linux-rdma@vger.kernel.org
 Description:	HCA name (<hca>).
 What:		/sys/class/infiniband_srp/srp-<hca>-<port_number>/port
 Date:		January 2, 2006
 KernelVersion:	2.6.15
 Contact:	linux-rdma@vger.kernel.org
 Description:	HCA port number (<port_number>).
 What:		/sys/class/scsi_host/host<n>/allow_ext_sg
 Date:		May 19, 2011
 KernelVersion:	2.6.39
 Contact:	linux-rdma@vger.kernel.org
 Description:	Whether ib_srp is allowed to include a partial memory
 		descriptor list in an SRP_CMD when communicating with an SRP
 		target.
 What:		/sys/class/scsi_host/host<n>/cmd_sg_entries
 Date:		May 19, 2011
 KernelVersion:	2.6.39
 Contact:	linux-rdma@vger.kernel.org
 Description:	Maximum number of data buffer descriptors that may be sent to
 		the target in a single SRP_CMD request.
 What:		/sys/class/scsi_host/host<n>/dgid
 Date:		June 17, 2006
 KernelVersion:	2.6.17
 Contact:	linux-rdma@vger.kernel.org
 Description:	InfiniBand destination GID used for communication with the SRP
 		target. Differs from orig_dgid if port redirection has happened.
 What:		/sys/class/scsi_host/host<n>/id_ext
 Date:		June 17, 2006
 KernelVersion:	2.6.17
 Contact:	linux-rdma@vger.kernel.org
 Description:	Eight-byte identifier extension portion of the 16-byte target
 		port identifier.
 What:		/sys/class/scsi_host/host<n>/ioc_guid
 Date:		June 17, 2006
 KernelVersion:	2.6.17
 Contact:	linux-rdma@vger.kernel.org
 Description:	Eight-byte I/O controller GUID portion of the 16-byte target
 		port identifier.
 What:		/sys/class/scsi_host/host<n>/local_ib_device
 Date:		November 29, 2006
 KernelVersion:	2.6.19
 Contact:	linux-rdma@vger.kernel.org
 Description:	Name of the InfiniBand HCA used for communicating with the
 		SRP target.
 What:		/sys/class/scsi_host/host<n>/local_ib_port
 Date:		November 29, 2006
 KernelVersion:	2.6.19
 Contact:	linux-rdma@vger.kernel.org
 Description:	Number of the HCA port used for communicating with the
 		SRP target.
 What:		/sys/class/scsi_host/host<n>/orig_dgid
 Date:		June 17, 2006
 KernelVersion:	2.6.17
 Contact:	linux-rdma@vger.kernel.org
 Description:	InfiniBand destination GID specified in the parameters
 		written to the add_target sysfs attribute.
 What:		/sys/class/scsi_host/host<n>/pkey
 Date:		June 17, 2006
 KernelVersion:	2.6.17
 Contact:	linux-rdma@vger.kernel.org
 Description:	A 16-bit number representing the InfiniBand partition key used
 		for communication with the SRP target.
 What:		/sys/class/scsi_host/host<n>/req_lim
 Date:		October 20, 2010
 KernelVersion:	2.6.36
 Contact:	linux-rdma@vger.kernel.org
 Description:	Number of requests ib_srp can send to the target before it has
 		to wait for more credits. For more information see also the
 		SRP credit algorithm in the SRP specification.
 What:		/sys/class/scsi_host/host<n>/service_id
 Date:		June 17, 2006
 KernelVersion:	2.6.17
 Contact:	linux-rdma@vger.kernel.org
 Description:	InfiniBand service ID used for establishing communication with
 		the SRP	target.
 What:		/sys/class/scsi_host/host<n>/zero_req_lim
 Date:		September 20, 2006
 KernelVersion:	2.6.18
 Contact:	linux-rdma@vger.kernel.org
 Description:	Number of times the initiator had to wait before sending a
 		request to the target because it ran out of credits. For more
 		information see also the SRP credit algorithm in the SRP
 		specification.
--- a/Documentation/ABI/stable/sysfs-transport-srp
+++ b/Documentation/ABI/stable/sysfs-transport-srp
@@ -0,0 +1,19 @@
 What:		/sys/class/srp_remote_ports/port-<h>:<n>/delete
 Date:		June 1, 2012
 KernelVersion:	3.7
 Contact:	linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
 Description:	Instructs an SRP initiator to disconnect from a target and to
 		remove all LUNs imported from that target.
 What:		/sys/class/srp_remote_ports/port-<h>:<n>/port_id
 Date:		June 27, 2007
 KernelVersion:	2.6.24
 Contact:	linux-scsi@vger.kernel.org
 Description:	16-byte local SRP port identifier in hexadecimal format. An
 		example: 4c:49:4e:55:58:20:56:49:4f:00:00:00:00:00:00:00.
 What:		/sys/class/srp_remote_ports/port-<h>:<n>/roles
 Date:		June 27, 2007
 KernelVersion:	2.6.24
 Contact:	linux-scsi@vger.kernel.org
 Description:	Role of the remote port. Either "SRP Initiator" or "SRP Target".
--- a/Documentation/ABI/testing/dev-kmsg
+++ b/Documentation/ABI/testing/dev-kmsg
@@ -92,7 +92,7 @@ Description:	The /dev/kmsg character device node provides userspace access
 		The flags field carries '-' by default. A 'c' indicates a
 		fragment of a line. All following fragments are flagged with
 		'+'. Note, that these hints about continuation lines are not
-		neccessarily correct, and the stream could be interleaved with
+		necessarily correct, and the stream could be interleaved with
 		unrelated messages, but merging the lines in the output
 		usually produces better human readable results. A similar
 		logic is used internally when messages are printed to the
--- 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]
+		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
@@ -53,6 +57,7 @@ Description:
 			measure func=BPRM_CHECK
 			measure func=FILE_MMAP mask=MAY_EXEC
 			measure func=FILE_CHECK mask=MAY_READ uid=0
 			measure func=MODULE_CHECK uid=0
 			appraise fowner=0
 		The default policy measures all executables in bprm_check,
--- 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.
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ 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.
--- a/Documentation/ABI/testing/sysfs-bus-fcoe
+++ b/Documentation/ABI/testing/sysfs-bus-fcoe
@@ -1,14 +1,53 @@
-What:		/sys/bus/fcoe/ctlr_X
+What:		/sys/bus/fcoe/
 Date:		August 2012
 KernelVersion:	TBD
 Contact:	Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
 Description:	The FCoE bus. Attributes in this directory are control interfaces.
 Attributes:
 	ctlr_create: 'FCoE Controller' instance creation interface. Writing an
 		     <ifname> to this file will allocate and populate sysfs with a
 		     fcoe_ctlr_device (ctlr_X). The user can then configure any
 		     per-port settings and finally write to the fcoe_ctlr_device's
 		     'start' attribute to begin the kernel's discovery and login
 		     process.
 	ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a
 		       fcoe_ctlr_device's sysfs name to this file will log the
 		       fcoe_ctlr_device out of the fabric or otherwise connected
 		       FCoE devices. It will also free all kernel memory allocated
 		       for this fcoe_ctlr_device and any structures associated
 		       with it, this includes the scsi_host.
 What:		/sys/bus/fcoe/devices/ctlr_X
 Date:		March 2012
 KernelVersion:	TBD
 Contact:	Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
-Description:	'FCoE Controller' instances on the fcoe bus
+Description:	'FCoE Controller' instances on the fcoe bus.
 		The FCoE Controller now has a three stage creation process.
 		1) Write interface name to ctlr_create 2) Configure the FCoE
 		Controller (ctlr_X) 3) Enable the FCoE Controller to begin
 		discovery and login. The FCoE Controller is destroyed by
 		writing it's name, i.e. ctlr_X to the ctlr_delete file.
 Attributes:
 	fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
 			  this value will change the dev_loss_tmo for all
 			  FCFs discovered by this controller.
 	mode:		  Display or change the FCoE Controller's mode. Possible
 			  modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
 			  is started in 'Fabric' mode then FIP FCF discovery is
 			  initiated and ultimately a fabric login is attempted.
 			  If a FCoE Controller is started in 'VN2VN' mode then
 			  FIP VN2VN discovery and login is performed. A FCoE
 			  Controller only supports one mode at a time.
 	enabled:	  Whether an FCoE controller is enabled or disabled.
 			  0 if disabled, 1 if enabled. Writing either 0 or 1
 			  to this file will enable or disable the FCoE controller.
 	lesb/link_fail:   Link Error Status Block (LESB) link failure count.
 	lesb/vlink_fail:  Link Error Status Block (LESB) virtual link
@@ -26,7 +65,7 @@ Attributes:
 Notes: ctlr_X (global increment starting at 0)
-What:		/sys/bus/fcoe/fcf_X
+What:		/sys/bus/fcoe/devices/fcf_X
 Date:		March 2012
 KernelVersion:	TBD
 Contact:	Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -189,6 +189,14 @@ Description:
 		A computed peak value based on the sum squared magnitude of
 		the underlying value in the specified directions.
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressureY_raw
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressure_raw
 KernelVersion:	3.8
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Raw pressure measurement from channel Y. Units after
 		application of scale and offset are kilopascal.
 What:		/sys/bus/iio/devices/iio:deviceX/in_accel_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_accel_y_offset
@@ -197,6 +205,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_tempY_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_temp_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressureY_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressure_offset
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -226,6 +236,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_magn_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_magn_z_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressure_scale
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -245,6 +257,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias
 What:		/sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias
 What:		/sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibbias
 What:		/sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressureY_calibbias
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressure_calibbias
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -262,6 +276,8 @@ What		/sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibscale
 What		/sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibscale
 what		/sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibscale
 what		/sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressureY_calibscale
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressure_calibscale
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -275,6 +291,8 @@ What:		/sys/.../iio:deviceX/in_voltage-voltage_scale_available
 What:		/sys/.../iio:deviceX/out_voltageX_scale_available
 What:		/sys/.../iio:deviceX/out_altvoltageX_scale_available
 What:		/sys/.../iio:deviceX/in_capacitance_scale_available
 What:		/sys/.../iio:deviceX/in_pressure_scale_available
 What:		/sys/.../iio:deviceX/in_pressureY_scale_available
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -694,6 +712,8 @@ What:		/sys/.../buffer/scan_elements/in_voltageY_en
 What:		/sys/.../buffer/scan_elements/in_voltageY-voltageZ_en
 What:		/sys/.../buffer/scan_elements/in_incli_x_en
 What:		/sys/.../buffer/scan_elements/in_incli_y_en
 What:		/sys/.../buffer/scan_elements/in_pressureY_en
 What:		/sys/.../buffer/scan_elements/in_pressure_en
 KernelVersion:	2.6.37
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -707,6 +727,8 @@ What:		/sys/.../buffer/scan_elements/in_voltageY_type
 What:		/sys/.../buffer/scan_elements/in_voltage_type
 What:		/sys/.../buffer/scan_elements/in_voltageY_supply_type
 What:		/sys/.../buffer/scan_elements/in_timestamp_type
 What:		/sys/.../buffer/scan_elements/in_pressureY_type
 What:		/sys/.../buffer/scan_elements/in_pressure_type
 KernelVersion:	2.6.37
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -751,6 +773,8 @@ What:		/sys/.../buffer/scan_elements/in_magn_z_index
 What:		/sys/.../buffer/scan_elements/in_incli_x_index
 What:		/sys/.../buffer/scan_elements/in_incli_y_index
 What:		/sys/.../buffer/scan_elements/in_timestamp_index
 What:		/sys/.../buffer/scan_elements/in_pressureY_index
 What:		/sys/.../buffer/scan_elements/in_pressure_index
 KernelVersion:	2.6.37
 Contact:	linux-iio@vger.kernel.org
 Description:
--- a/Documentation/ABI/testing/sysfs-bus-iio-mpu6050
+++ 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.
--- a/Documentation/ABI/testing/sysfs-bus-mdio
+++ b/Documentation/ABI/testing/sysfs-bus-mdio
@@ -0,0 +1,9 @@
 What:		/sys/bus/mdio_bus/devices/.../phy_id
 Date:		November 2012
 KernelVersion:	3.8
 Contact:	netdev@vger.kernel.org
 Description:
 		This attribute contains the 32-bit PHY Identifier as reported
 		by the device during bus enumeration, encoded in hexadecimal.
 		This ID is used to match the device with the appropriate
 		driver.
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -222,3 +222,37 @@ Description:
 		satisfied too.  Reading this attribute will show the current
 		value of d3cold_allowed bit.  Writing this attribute will set
 		the value of d3cold_allowed bit.
 What:		/sys/bus/pci/devices/.../sriov_totalvfs
 Date:		November 2012
 Contact:	Donald Dutile <ddutile@redhat.com>
 Description:
 		This file appears when a physical PCIe device supports SR-IOV.
 		Userspace applications can read this file to determine the
 		maximum number of Virtual Functions (VFs) a PCIe physical
 		function (PF) can support. Typically, this is the value reported
 		in the PF's SR-IOV extended capability structure's TotalVFs
 		element.  Drivers have the ability at probe time to reduce the
 		value read from this file via the pci_sriov_set_totalvfs()
 		function.
 What:		/sys/bus/pci/devices/.../sriov_numvfs
 Date:		November 2012
 Contact:	Donald Dutile <ddutile@redhat.com>
 Description:
 		This file appears when a physical PCIe device supports SR-IOV.
 		Userspace applications can read and write to this file to
 		determine and control the enablement or disablement of Virtual
 		Functions (VFs) on the physical function (PF). A read of this
 		file will return the number of VFs that are enabled on this PF.
 		A number written to this file will enable the specified
 		number of VFs. A userspace application would typically read the
 		file and check that the value is zero, and then write the number
 		of VFs that should be enabled on the PF; the value written
 		should be less than or equal to the value in the sriov_totalvfs
 		file. A userspace application wanting to disable the VFs would
 		write a zero to this file. The core ensures that valid values
 		are written to this file, and returns errors when values are not
 		valid.  For example, writing a 2 to this file when sriov_numvfs
 		is not 0 and not 2 already will return an error. Writing a 10
 		when the value of sriov_totalvfs is 8 will return an error.
--- a/Documentation/ABI/testing/sysfs-bus-rbd
+++ b/Documentation/ABI/testing/sysfs-bus-rbd
@@ -70,6 +70,10 @@ snap_*
 	A directory per each snapshot
 parent
 	Information identifying the pool, image, and snapshot id for
 	the parent image in a layered rbd image (format 2 only).
 Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
 -------------------------------------------------------------
--- 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.
--- 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.
--- a/Documentation/ABI/testing/sysfs-class-devfreq
+++ b/Documentation/ABI/testing/sysfs-class-devfreq
@@ -11,7 +11,7 @@ What:		/sys/class/devfreq/.../governor
 Date:		September 2011
 Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
 Description:
-		The /sys/class/devfreq/.../governor shows the name of the
+		The /sys/class/devfreq/.../governor show or set the name of the
 		governor used by the corresponding devfreq object.
 What:		/sys/class/devfreq/.../cur_freq
@@ -19,15 +19,16 @@ Date:		September 2011
 Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
 Description:
 		The /sys/class/devfreq/.../cur_freq shows the current
-		frequency of the corresponding devfreq object.
+		frequency of the corresponding devfreq object. Same as
 		target_freq when get_cur_freq() is not implemented by
 		devfreq driver.
-What:		/sys/class/devfreq/.../central_polling
+What:		/sys/class/devfreq/.../target_freq
-Date:		September 2011
+Date:		September 2012
-Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
+Contact:	Rajagopal Venkat <rajagopal.venkat@linaro.org>
 Description:
-		The /sys/class/devfreq/.../central_polling shows whether
+		The /sys/class/devfreq/.../target_freq shows the next governor
-		the devfreq ojbect is using devfreq-provided central
+		predicted target frequency of the corresponding devfreq object.
 		polling mechanism or not.
 What:		/sys/class/devfreq/.../polling_interval
 Date:		September 2011
@@ -43,6 +44,17 @@ Description:
 		(/sys/class/devfreq/.../central_polling is 0), this value
 		may be useless.
 What:		/sys/class/devfreq/.../trans_stat
 Date:		October 2012
 Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
 Descrtiption:
 		This ABI shows the statistics of devfreq behavior on a
 		specific device. It shows the time spent in each state and
 		the number of transitions between states.
 		In order to activate this ABI, the devfreq target device
 		driver should provide the list of available frequencies
 		with its profile.
 What:		/sys/class/devfreq/.../userspace/set_freq
 Date:		September 2011
 Contact:	MyungJoo Ham <myungjoo.ham@samsung.com>
@@ -50,3 +62,19 @@ Description:
 		The /sys/class/devfreq/.../userspace/set_freq shows and
 		sets the requested frequency for the devfreq object if
 		userspace governor is in effect.
 What:		/sys/class/devfreq/.../available_frequencies
 Date:		October 2012
 Contact:	Nishanth Menon <nm@ti.com>
 Description:
 		The /sys/class/devfreq/.../available_frequencies shows
 		the available frequencies of the corresponding devfreq object.
 		This is a snapshot of available frequencies and not limited
 		by the min/max frequency restrictions.
 What:		/sys/class/devfreq/.../available_governors
 Date:		October 2012
 Contact:	Nishanth Menon <nm@ti.com>
 Description:
 		The /sys/class/devfreq/.../available_governors shows
 		currently available governors in the system.
--- a/Documentation/ABI/testing/sysfs-class-net-batman-adv
+++ b/Documentation/ABI/testing/sysfs-class-net-batman-adv
@@ -1,4 +1,10 @@
 What:           /sys/class/net/<iface>/batman-adv/iface_status
 Date:           May 2010
 Contact:        Marek Lindner <lindner_marek@yahoo.de>
 Description:
                Indicates the status of <iface> as it is seen by batman.
 What:           /sys/class/net/<iface>/batman-adv/mesh_iface
 Date:           May 2010
 Contact:        Marek Lindner <lindner_marek@yahoo.de>
@@ -7,8 +13,3 @@ Description:
                displays the batman mesh interface this <iface>
                currently is associated with.
 What:           /sys/class/net/<iface>/batman-adv/iface_status
 Date:           May 2010
 Contact:        Marek Lindner <lindner_marek@yahoo.de>
 Description:
                Indicates the status of <iface> as it is seen by batman.
--- a/Documentation/ABI/testing/sysfs-class-net-grcan
+++ b/Documentation/ABI/testing/sysfs-class-net-grcan
@@ -0,0 +1,35 @@
 What:		/sys/class/net/<iface>/grcan/enable0
 Date:		October 2012
 KernelVersion:	3.8
 Contact:	Andreas Larsson <andreas@gaisler.com>
 Description:
 		Hardware configuration of physical interface 0. This file reads
 		and writes the "Enable 0" bit of the configuration register.
 		Possible values: 0 or 1. See the GRCAN chapter of the GRLIB IP
 		core library documentation for details. The default value is 0
 		or set by the module parameter grcan.enable0 and can be read at
 		/sys/module/grcan/parameters/enable0.
 What:		/sys/class/net/<iface>/grcan/enable1
 Date:		October 2012
 KernelVersion:	3.8
 Contact:	Andreas Larsson <andreas@gaisler.com>
 Description:
 		Hardware configuration of physical interface 1. This file reads
 		and writes the "Enable 1" bit of the configuration register.
 		Possible values: 0 or 1. See the GRCAN chapter of the GRLIB IP
 		core library documentation for details. The default value is 0
 		or set by the module parameter grcan.enable1 and can be read at
 		/sys/module/grcan/parameters/enable1.
 What:		/sys/class/net/<iface>/grcan/select
 Date:		October 2012
 KernelVersion:	3.8
 Contact:	Andreas Larsson <andreas@gaisler.com>
 Description:
 		Configuration of which physical interface to be used. Possible
 		values: 0 or 1. See the GRCAN chapter of the GRLIB IP core
 		library documentation for details. The default value is 0 or is
 		set by the module parameter grcan.select and can be read at
 		/sys/module/grcan/parameters/select.
--- a/Documentation/ABI/testing/sysfs-class-net-mesh
+++ b/Documentation/ABI/testing/sysfs-class-net-mesh
@@ -6,6 +6,14 @@ Description:
                Indicates whether the batman protocol messages of the
                mesh <mesh_iface> shall be aggregated or not.
 What:           /sys/class/net/<mesh_iface>/mesh/ap_isolation
 Date:           May 2011
 Contact:        Antonio Quartulli <ordex@autistici.org>
 Description:
                Indicates whether the data traffic going from a
                wireless client to another wireless client will be
                silently dropped.
 What:           /sys/class/net/<mesh_iface>/mesh/bonding
 Date:           June 2010
 Contact:        Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
@@ -31,14 +39,6 @@ Description:
                mesh will be fragmented or silently discarded if the
                packet size exceeds the outgoing interface MTU.
 What:		/sys/class/net/<mesh_iface>/mesh/ap_isolation
 Date:		May 2011
 Contact:	Antonio Quartulli <ordex@autistici.org>
 Description:
 		Indicates whether the data traffic going from a
 		wireless client to another wireless client will be
 		silently dropped.
 What:           /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
 Date:           October 2010
 Contact:        Marek Lindner <lindner_marek@yahoo.de>
@@ -60,6 +60,13 @@ Description:
                Defines the selection criteria this node will use
                to choose a gateway if gw_mode was set to 'client'.
 What:           /sys/class/net/<mesh_iface>/mesh/hop_penalty
 Date:           Oct 2010
 Contact:        Linus Lüssing <linus.luessing@web.de>
 Description:
                Defines the penalty which will be applied to an
                originator message's tq-field on every hop.
 What:           /sys/class/net/<mesh_iface>/mesh/orig_interval
 Date:           May 2010
 Contact:        Marek Lindner <lindner_marek@yahoo.de>
@@ -67,19 +74,12 @@ Description:
                Defines the interval in milliseconds in which batman
                sends its protocol messages.
-What:           /sys/class/net/<mesh_iface>/mesh/hop_penalty
+What:           /sys/class/net/<mesh_iface>/mesh/routing_algo
-Date:           Oct 2010
+Date:           Dec 2011
-Contact:        Linus Lüssing <linus.luessing@web.de>
+Contact:        Marek Lindner <lindner_marek@yahoo.de>
 Description:
-		Defines the penalty which will be applied to an
+                Defines the routing procotol this mesh instance
-		originator message's tq-field on every hop.
+                uses to find the optimal paths through the mesh.
 What:		/sys/class/net/<mesh_iface>/mesh/routing_algo
 Date:		Dec 2011
 Contact:	Marek Lindner <lindner_marek@yahoo.de>
 Description:
 		Defines the routing procotol this mesh instance
 		uses to find the optimal paths through the mesh.
 What:           /sys/class/net/<mesh_iface>/mesh/vis_mode
 Date:           May 2010
--- a/Documentation/ABI/testing/sysfs-devices-node
+++ b/Documentation/ABI/testing/sysfs-devices-node
@@ -1,7 +0,0 @@
 What:		/sys/devices/system/node/nodeX/compact
 Date:		February 2010
 Contact:	Mel Gorman <mel@csn.ul.ie>
 Description:
 		When this file is written to, all memory within that node
 		will be compacted. When it completes, memory will be freed
 		into blocks which have as many contiguous pages as possible
--- a/Documentation/ABI/testing/sysfs-devices-power
+++ b/Documentation/ABI/testing/sysfs-devices-power
@@ -164,7 +164,7 @@ Contact:	Rafael J. Wysocki <rjw@sisk.pl>
 Description:
 		The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
 		contains the total time the device has been preventing
-		opportunistic transitions to sleep states from occuring.
+		opportunistic transitions to sleep states from occurring.
 		This attribute is read-only.  If the device is not enabled to
 		wake up the system from sleep states, this attribute is not
 		present.
@@ -204,3 +204,34 @@ Description:
 		This attribute has no effect on system-wide suspend/resume and
 		hibernation.
 What:		/sys/devices/.../power/pm_qos_no_power_off
 Date:		September 2012
 Contact:	Rafael J. Wysocki <rjw@sisk.pl>
 Description:
 		The /sys/devices/.../power/pm_qos_no_power_off attribute
 		is used for manipulating the PM QoS "no power off" flag.  If
 		set, this flag indicates to the kernel that power should not
 		be removed entirely from the device.
 		Not all drivers support this attribute.  If it isn't supported,
 		it is not present.
 		This attribute has no effect on system-wide suspend/resume and
 		hibernation.
 What:		/sys/devices/.../power/pm_qos_remote_wakeup
 Date:		September 2012
 Contact:	Rafael J. Wysocki <rjw@sisk.pl>
 Description:
 		The /sys/devices/.../power/pm_qos_remote_wakeup attribute
 		is used for manipulating the PM QoS "remote wakeup required"
 		flag.  If set, this flag indicates to the kernel that the
 		device is a source of user events that have to be signaled from
 		its low-power states.
 		Not all drivers support this attribute.  If it isn't supported,
 		it is not present.
 		This attribute has no effect on system-wide suspend/resume and
 		hibernation.
--- a/Documentation/ABI/testing/sysfs-devices-power_resources_D0
+++ 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.
--- a/Documentation/ABI/testing/sysfs-devices-power_resources_D1
+++ 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.
--- a/Documentation/ABI/testing/sysfs-devices-power_resources_D2
+++ 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.
--- a/Documentation/ABI/testing/sysfs-devices-power_resources_D3hot
+++ 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.
--- a/Documentation/ABI/testing/sysfs-devices-power_state
+++ 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.
--- a/Documentation/ABI/testing/sysfs-devices-real_power_state
+++ 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.
--- a/Documentation/ABI/testing/sysfs-devices-resource_in_use
+++ 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.
--- a/Documentation/ABI/testing/sysfs-devices-sun
+++ b/Documentation/ABI/testing/sysfs-devices-sun
@@ -0,0 +1,14 @@
 Whatt:		/sys/devices/.../sun
 Date:		October 2012
 Contact:	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
 Description:
 		The file contains a Slot-unique ID which provided by the _SUN
 		method in the ACPI namespace. The value is written in Advanced
 		Configuration and Power Interface Specification as follows:
 		"The _SUN value is required to be unique among the slots of
 		the same type. It is also recommended that this number match
 		the slot number printed on the physical slot whenever possible."
 		So reading the sysfs file, we can identify a physical position
 		of the slot in the system.
--- 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
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
@@ -117,6 +117,14 @@ Description:	When written, this file lets one store macros with max 500
 		which profile and key to read.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/reset
 Date:		November 2012
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	When written, this file lets one reset the device.
 		The data has to be 3 bytes long.
 		This file is writeonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/control
 Date:		June 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
@@ -9,15 +9,12 @@ Description:	The integer value of this attribute ranges from 0-4.
 		and the mouse activates this profile immediately.
 Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/info
-Date:		October 2010
+Date:		November 2012
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	When read, this file returns the raw integer version number of the
+Description:	When read, this file returns general data like firmware version.
-		firmware reported by the mouse. Using the integer value eases
+		When written, the device can be reset.
-		further usage in other programs. To receive the real version
+		The data is 8 bytes long.
 		number the decimal point has to be shifted 2 positions to the
 		left. E.g. a returned value of 121 means 1.21
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/macro
@@ -42,18 +39,8 @@ Description:	The mouse can store 5 profiles which can be switched by the
 		The mouse will reject invalid data.
 		Which profile to write is determined by the profile number
 		contained in the data.
-		This file is writeonly.
+		Before reading this file, control has to be written to select
-Users:		http://roccat.sourceforge.net
+		which profile to read.
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_buttons holds information about button layout.
 		When read, these files return the respective profile buttons.
 		The returned data is 77 bytes in size.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_settings
@@ -68,19 +55,8 @@ Description:	The mouse can store 5 profiles which can be switched by the
 		The mouse will reject invalid data.
 		Which profile to write is determined by the profile number
 		contained in the data.
-		This file is writeonly.
+		Before reading this file, control has to be written to select
-Users:		http://roccat.sourceforge.net
+		which profile to read.
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_settings holds information like resolution, sensitivity
 		and light effects.
 		When read, these files return the respective profile settings.
 		The returned data is 43 bytes in size.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/sensor
@@ -104,9 +80,9 @@ What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-
 Date:		October 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	When written a calibration process for the tracking control unit
-		can be initiated/cancelled.
+		can be initiated/cancelled. Also lets one read/write sensor
-		The data has to be 3 bytes long.
+		registers.
-		This file is writeonly.
+		The data has to be 4 bytes long.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu_image
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus
@@ -1,12 +1,3 @@
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_cpi
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The integer value of this attribute ranges from 1-4.
 		When read, this attribute returns the number of the active
 		cpi level.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_profile
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
@@ -18,33 +9,12 @@ Description:	The integer value of this attribute ranges from 0-4.
 		active when the mouse is powered on.
 Users:		http://roccat.sourceforge.net
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_x
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/info
-Date:		January 2011
+Date:		November 2012
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The integer value of this attribute ranges from 1-10.
+Description:	When read, this file returns general data like firmware version.
-		When read, this attribute returns the number of the actual
+		When written, the device can be reset.
-		sensitivity in x direction.
+		The data is 6 bytes long.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_y
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The integer value of this attribute ranges from 1-10.
 		When read, this attribute returns the number of the actual
 		sensitivity in y direction.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/firmware_version
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	When read, this file returns the raw integer version number of the
 		firmware reported by the mouse. Using the integer value eases
 		further usage in other programs. To receive the real version
 		number the decimal point has to be shifted 2 positions to the
 		left. E.g. a returned value of 121 means 1.21
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_buttons
@@ -58,18 +28,8 @@ Description:	The mouse can store 5 profiles which can be switched by the
 		The mouse will reject invalid data.
 		Which profile to write is determined by the profile number
 		contained in the data.
-		This file is writeonly.
+		Before reading this file, control has to be written to select
-Users:		http://roccat.sourceforge.net
+		which profile to read.
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_buttons
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_buttons holds information about button layout.
 		When read, these files return the respective profile buttons.
 		The returned data is 23 bytes in size.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_settings
@@ -84,17 +44,6 @@ Description:	The mouse can store 5 profiles which can be switched by the
 		The mouse will reject invalid data.
 		Which profile to write is determined by the profile number
 		contained in the data.
-		This file is writeonly.
+		Before reading this file, control has to be written to select
-Users:		http://roccat.sourceforge.net
+		which profile to read.
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_settings
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_settings holds information like resolution, sensitivity
 		and light effects.
 		When read, these files return the respective profile settings.
 		The returned data is 16 bytes in size.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-lua
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-lua
@@ -0,0 +1,7 @@
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/control
 Date:		October 2012
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	When written, cpi, button and light settings can be configured.
 		When read, actual cpi setting and sensor data are returned.
 		The data has to be 8 bytes long.
 Users:		http://roccat.sourceforge.net
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
@@ -1,37 +1,9 @@
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_cpi
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/info
-Date:		August 2010
+Date:		November 2012
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	It is possible to switch the cpi setting of the mouse with the
+Description:	When read, this file returns general data like firmware version.
-		press of a button.
+		When written, the device can be reset.
-		When read, this file returns the raw number of the actual cpi
+		The data is 6 bytes long.
 		setting reported by the mouse. This number has to be further
 		processed to receive the real dpi value.
 		VALUE DPI
 		1     400
 		2     800
 		4     1600
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	When read, this file returns the number of the actual profile in
 		range 0-4.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	When read, this file returns the raw integer version number of the
 		firmware reported by the mouse. Using the integer value eases
 		further usage in other programs. To receive the real version
 		number the decimal point has to be shifted 2 positions to the
 		left. E.g. a returned value of 138 means 1.38
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_settings
@@ -46,19 +18,8 @@ Description:	The mouse can store 5 profiles which can be switched by the
 		The mouse will reject invalid data.
 		Which profile to write is determined by the profile number
 		contained in the data.
-		This file is writeonly.
+		Before reading this file, control has to be written to select
-Users:		http://roccat.sourceforge.net
+		which profile to read.
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_settings
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_settings holds information like resolution, sensitivity
 		and light effects.
 		When read, these files return the respective profile settings.
 		The returned data is 13 bytes in size.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_buttons
@@ -72,27 +33,8 @@ Description:	The mouse can store 5 profiles which can be switched by the
 		The mouse will reject invalid data.
 		Which profile to write is determined by the profile number
 		contained in the data.
-		This file is writeonly.
+		Before reading this file, control has to be written to select
-Users:		http://roccat.sourceforge.net
+		which profile to read.
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_buttons
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The mouse can store 5 profiles which can be switched by the
 		press of a button. A profile is split in settings and buttons.
 		profile_buttons holds information about button layout.
 		When read, these files return the respective profile buttons.
 		The returned data is 19 bytes in size.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	The integer value of this attribute ranges from 0-4.
                When read, this attribute returns the number of the profile
                that's active when the mouse is powered on.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/settings
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu
@@ -40,8 +40,8 @@ What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-
 Date:		Mai 2012
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:	When read, this file returns general data like firmware version.
 		When written, the device can be reset.
 		The data is 8 bytes long.
 		This file is readonly.
 Users:		http://roccat.sourceforge.net
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/macro
@@ -74,4 +74,3 @@ Description:	The mouse has a Avago ADNS-3090 sensor.
 		This file allows reading and writing of the mouse sensors registers.
 		The data has to be 4 bytes long.
 Users:		http://roccat.sourceforge.net
--- a/Documentation/ABI/testing/sysfs-driver-hid-srws1
+++ 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
--- a/Documentation/ABI/testing/sysfs-driver-hid-thingm
+++ 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.
--- a/Documentation/ABI/testing/sysfs-driver-ppi
+++ b/Documentation/ABI/testing/sysfs-driver-ppi
@@ -5,7 +5,7 @@ Contact:	xiaoyan.zhang@intel.com
 Description:
 		This folder includes the attributes related with PPI (Physical
 		Presence Interface). Only if TPM is supported by BIOS, this
-		folder makes sence. The folder path can be got by command
+		folder makes sense. The folder path can be got by command
 		'find /sys/ -name 'pcrs''. For the detail information of PPI,
 		please refer to the PPI specification from
 		http://www.trustedcomputinggroup.org/
--- a/Documentation/ABI/testing/sysfs-kernel-mm-ksm
+++ 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).
--- a/Documentation/ABI/testing/sysfs-platform-msi-laptop
+++ b/Documentation/ABI/testing/sysfs-platform-msi-laptop
@@ -0,0 +1,83 @@
 What:		/sys/devices/platform/msi-laptop-pf/lcd_level
 Date:		Oct 2006
 KernelVersion:	2.6.19
 Contact:	"Lennart Poettering <mzxreary@0pointer.de>"
 Description:
 		Screen brightness: contains a single integer in the range 0..8.
 What:		/sys/devices/platform/msi-laptop-pf/auto_brightness
 Date:		Oct 2006
 KernelVersion:	2.6.19
 Contact:	"Lennart Poettering <mzxreary@0pointer.de>"
 Description:
 		Enable automatic brightness control: contains either 0 or 1. If
 		set to 1 the hardware adjusts the screen brightness
 		automatically when the power cord is plugged/unplugged.
 What:		/sys/devices/platform/msi-laptop-pf/wlan
 Date:		Oct 2006
 KernelVersion:	2.6.19
 Contact:	"Lennart Poettering <mzxreary@0pointer.de>"
 Description:
 		WLAN subsystem enabled: contains either 0 or 1.
 What:		/sys/devices/platform/msi-laptop-pf/bluetooth
 Date:		Oct 2006
 KernelVersion:	2.6.19
 Contact:	"Lennart Poettering <mzxreary@0pointer.de>"
 Description:
 		Bluetooth subsystem enabled: contains either 0 or 1. Please
 		note that this file is constantly 0 if no Bluetooth hardware is
 		available.
 What:		/sys/devices/platform/msi-laptop-pf/touchpad
 Date:		Nov 2012
 KernelVersion:	3.8
 Contact:	"Maxim Mikityanskiy <maxtram95@gmail.com>"
 Description:
 		Contains either 0 or 1 and indicates if touchpad is turned on.
 		Touchpad state can only be toggled by pressing Fn+F3.
 What:		/sys/devices/platform/msi-laptop-pf/turbo_mode
 Date:		Nov 2012
 KernelVersion:	3.8
 Contact:	"Maxim Mikityanskiy <maxtram95@gmail.com>"
 Description:
 		Contains either 0 or 1 and indicates if turbo mode is turned
 		on. In turbo mode power LED is orange and processor is
 		overclocked. Turbo mode is available only if charging. It is
 		only possible to toggle turbo mode state by pressing Fn+F10,
 		and there is a few seconds cooldown between subsequent toggles.
 		If user presses Fn+F10 too frequent, turbo mode state is not
 		changed.
 What:		/sys/devices/platform/msi-laptop-pf/eco_mode
 Date:		Nov 2012
 KernelVersion:	3.8
 Contact:	"Maxim Mikityanskiy <maxtram95@gmail.com>"
 Description:
 		Contains either 0 or 1 and indicates if ECO mode is turned on.
 		In ECO mode power LED is green and userspace should do some
 		powersaving actions. ECO mode is available only on battery
 		power. ECO mode can only be toggled by pressing Fn+F10.
 What:		/sys/devices/platform/msi-laptop-pf/turbo_cooldown
 Date:		Nov 2012
 KernelVersion:	3.8
 Contact:	"Maxim Mikityanskiy <maxtram95@gmail.com>"
 Description:
 		Contains value in range 0..3:
 			* 0 -> Turbo mode is off
 			* 1 -> Turbo mode is on, cannot be turned off yet
 			* 2 -> Turbo mode is off, cannot be turned on yet
 			* 3 -> Turbo mode is on
 What:		/sys/devices/platform/msi-laptop-pf/auto_fan
 Date:		Nov 2012
 KernelVersion:	3.8
 Contact:	"Maxim Mikityanskiy <maxtram95@gmail.com>"
 Description:
 		Contains either 0 or 1 and indicates if fan speed is controlled
 		automatically (1) or fan runs at maximal speed (0). Can be
 		toggled in software.
--- a/Documentation/ABI/testing/sysfs-platform-ts5500
+++ 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".
--- a/Documentation/ABI/testing/sysfs-profiling
+++ b/Documentation/ABI/testing/sysfs-profiling
@@ -1,13 +1,13 @@
-What:		/sys/kernel/profile
+What:		/sys/kernel/profiling
 Date:		September 2008
 Contact:	Dave Hansen <dave@linux.vnet.ibm.com>
 Description:
-		/sys/kernel/profile is the runtime equivalent
+		/sys/kernel/profiling is the runtime equivalent
 		of the boot-time profile= option.
 		You can get the same effect running:
-			echo 2 > /sys/kernel/profile
+			echo 2 > /sys/kernel/profiling
 		as you would by issuing profile=2 on the boot
 		command line.
--- a/Documentation/ABI/testing/sysfs-tty
+++ b/Documentation/ABI/testing/sysfs-tty
@@ -26,3 +26,115 @@ Description:
 		 UART port in serial_core, that is bound to TTY like ttyS0.
 		 uartclk = 16 * baud_base
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/type
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 Shows the current tty type for this port.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/line
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 Shows the current tty line number for this port.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/port
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 Shows the current tty port I/O address for this port.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/irq
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 Shows the current primary interrupt for this port.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/flags
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 Show the tty port status flags for this port.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/xmit_fifo_size
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 Show the transmit FIFO size for this port.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/close_delay
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 Show the closing delay time for this port in ms.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/closing_wait
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 Show the close wait time for this port in ms.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/custom_divisor
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 Show the custom divisor if any that is set on this port.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/io_type
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 Show the I/O type that is to be used with the iomem base
 		 address.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/iomem_base
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 The I/O memory base for this port.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
 What:		/sys/class/tty/ttyS0/iomem_reg_shift
 Date:		October 2012
 Contact:	Alan Cox <alan@linux.intel.com>
 Description:
 		 Show the register shift indicating the spacing to be used
 		 for accesses on this iomem address.
 		 These sysfs values expose the TIOCGSERIAL interface via
 		 sysfs rather than via ioctls.
--- 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
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -468,11 +468,47 @@ To map a single region, you do:
 	size_t size = buffer->len;
 	dma_handle = dma_map_single(dev, addr, size, direction);
 	if (dma_mapping_error(dma_handle)) {
 		/*
 		 * reduce current DMA mapping usage,
 		 * delay and try again later or
 		 * reset driver.
 		 */
 		goto map_error_handling;
 	}
 and to unmap it:
 	dma_unmap_single(dev, dma_handle, size, direction);
 You should call dma_mapping_error() as dma_map_single() could fail and return
 error. Not all dma implementations support dma_mapping_error() interface.
 However, it is a good practice to call dma_mapping_error() interface, which
 will invoke the generic mapping error check interface. Doing so will ensure
 that the mapping code will work correctly on all dma implementations without
 any dependency on the specifics of the underlying implementation. Using the
 returned address without checking for errors could result in failures ranging
 from panics to silent data corruption. A couple of examples of incorrect ways
 to check for errors that make assumptions about the underlying dma
 implementation are as follows and these are applicable to dma_map_page() as
 well.
 Incorrect example 1:
 	dma_addr_t dma_handle;
 	dma_handle = dma_map_single(dev, addr, size, direction);
 	if ((dma_handle & 0xffff != 0) || (dma_handle >= 0x1000000)) {
 		goto map_error;
 	}
 Incorrect example 2:
 	dma_addr_t dma_handle;
 	dma_handle = dma_map_single(dev, addr, size, direction);
 	if (dma_handle == DMA_ERROR_CODE) {
 		goto map_error;
 	}
 You should call dma_unmap_single when the DMA activity is finished, e.g.
 from the interrupt which told you that the DMA transfer is done.
@@ -489,6 +525,14 @@ Specifically:
 	size_t size = buffer->len;
 	dma_handle = dma_map_page(dev, page, offset, size, direction);
 	if (dma_mapping_error(dma_handle)) {
 		/*
 		 * reduce current DMA mapping usage,
 		 * delay and try again later or
 		 * reset driver.
 		 */
 		goto map_error_handling;
 	}
 	...
@@ -496,6 +540,12 @@ Specifically:
 Here, "offset" means byte offset within the given page.
 You should call dma_mapping_error() as dma_map_page() could fail and return
 error as outlined under the dma_map_single() discussion.
 You should call dma_unmap_page when the DMA activity is finished, e.g.
 from the interrupt which told you that the DMA transfer is done.
 With scatterlists, you map a region gathered from several regions by:
 	int i, count = dma_map_sg(dev, sglist, nents, direction);
@@ -578,6 +628,14 @@ to use the dma_sync_*() interfaces.
 		dma_addr_t mapping;
 		mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE);
 		if (dma_mapping_error(dma_handle)) {
 			/*
 			 * reduce current DMA mapping usage,
 			 * delay and try again later or
 			 * reset driver.
 			 */
 			goto map_error_handling;
 		}
 		cp->rx_buf = buffer;
 		cp->rx_len = len;
@@ -658,6 +716,75 @@ failure can be determined by:
 		 * delay and try again later or
 		 * reset driver.
 		 */
 		goto map_error_handling;
 	}
 - unmap pages that are already mapped, when mapping error occurs in the middle
  of a multiple page mapping attempt. These example are applicable to
  dma_map_page() as well.
 Example 1:
 	dma_addr_t dma_handle1;
 	dma_addr_t dma_handle2;
 	dma_handle1 = dma_map_single(dev, addr, size, direction);
 	if (dma_mapping_error(dev, dma_handle1)) {
 		/*
 		 * reduce current DMA mapping usage,
 		 * delay and try again later or
 		 * reset driver.
 		 */
 		goto map_error_handling1;
 	}
 	dma_handle2 = dma_map_single(dev, addr, size, direction);
 	if (dma_mapping_error(dev, dma_handle2)) {
 		/*
 		 * reduce current DMA mapping usage,
 		 * delay and try again later or
 		 * reset driver.
 		 */
 		goto map_error_handling2;
 	}
 	...
 	map_error_handling2:
 		dma_unmap_single(dma_handle1);
 	map_error_handling1:
 Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when
 	    mapping error is detected in the middle)
 	dma_addr_t dma_addr;
 	dma_addr_t array[DMA_BUFFERS];
 	int save_index = 0;
 	for (i = 0; i < DMA_BUFFERS; i++) {
 		...
 		dma_addr = dma_map_single(dev, addr, size, direction);
 		if (dma_mapping_error(dev, dma_addr)) {
 			/*
 			 * reduce current DMA mapping usage,
 			 * delay and try again later or
 			 * reset driver.
 			 */
 			goto map_error_handling;
 		}
 		array[i].dma_addr = dma_addr;
 		save_index++;
 	}
 	...
 	map_error_handling:
 	for (i = 0; i < save_index; i++) {
 		...
 		dma_unmap_single(array[i].dma_addr);
 	}
 Networking drivers must call dev_kfree_skb to free the socket buffer
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -678,3 +678,15 @@ out of dma_debug_entries. These entries are preallocated at boot. The number
 of preallocated entries is defined per architecture. If it is too low for you
 boot with 'dma_debug_entries=<your_desired_number>' to overwrite the
 architectural default.
 void debug_dmap_mapping_error(struct device *dev, dma_addr_t dma_addr);
 dma-debug interface debug_dma_mapping_error() to debug drivers that fail
 to check dma mapping errors on addresses returned by dma_map_single() and
 dma_map_page() interfaces. This interface clears a flag set by
 debug_dma_map_page() to indicate that dma_mapping_error() has been called by
 the driver. When driver does unmap, debug_dma_unmap() checks the flag and if
 this flag is still set, prints warning message that includes call trace that
 leads up to the unmap. This interface can be called from dma_mapping_error()
 routines to enable dma mapping error check debugging.
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -91,3 +91,12 @@ transferred to 'device' domain. This attribute can be also used for
 dma_unmap_{single,page,sg} functions family to force buffer to stay in
 device domain after releasing a mapping for it. Use this attribute with
 care!
 DMA_ATTR_FORCE_CONTIGUOUS
 -------------------------
 By default DMA-mapping subsystem is allowed to assemble the buffer
 allocated by dma_alloc_attrs() function from individual pages if it can
 be mapped as contiguous chunk into device dma address space. By
 specifing this attribute the allocated buffer is forced to be contiguous
 also in physical memory.
--- 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
--- 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 -->
@@ -1125,6 +1160,12 @@ int max_width, max_height;</synopsis>
            without waiting for rendering or page flip to complete and must block
            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
@@ -1141,23 +1182,13 @@ int max_width, max_height;</synopsis>
            the <methodname>page_flip</methodname> operation will be called with a
            non-NULL <parameter>event</parameter> argument pointing to a
            <structname>drm_pending_vblank_event</structname> instance. Upon page
-            flip completion the driver must fill the
+            flip completion the driver must call <methodname>drm_send_vblank_event</methodname>
-            <parameter>event</parameter>::<structfield>event</structfield>
+            to fill in the event and send to wake up any waiting processes.
-            <structfield>sequence</structfield>, <structfield>tv_sec</structfield>
+            This can be performed with
            and <structfield>tv_usec</structfield> fields with the associated
            vertical blanking count and timestamp, add the event to the
            <parameter>drm_file</parameter> list of events to be signaled, and wake
            up any waiting process. This can be performed with
            <programlisting><![CDATA[
            struct timeval now;
            event->event.sequence = drm_vblank_count_and_time(..., &now);
            event->event.tv_sec = now.tv_sec;
            event->event.tv_usec = now.tv_usec;
            spin_lock_irqsave(&dev->event_lock, flags);
-            list_add_tail(&event->base.link, &event->base.file_priv->event_list);
+            ...
-            wake_up_interruptible(&event->base.file_priv->event_wait);
+            drm_send_vblank_event(dev, pipe, event);
            spin_unlock_irqrestore(&dev->event_lock, flags);
            ]]></programlisting>
          </para>
@@ -1619,12 +1650,16 @@ 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: mid-layer helper functions -->
+  <!-- Internals: kms helper functions -->
  <sect1>
-    <title>Mid-layer Helper Functions</title>
+    <title>Mode Setting Helper Functions</title>
    <para>
      The CRTC, encoder and connector functions provided by the drivers
      implement the DRM API. They're called by the DRM core and ioctl handlers
@@ -2106,6 +2141,26 @@ void intel_crt_init(struct drm_device *dev)
        </listitem>
      </itemizedlist>
    </sect2>
    <sect2>
      <title>Modeset Helper Functions Reference</title>
 !Edrivers/gpu/drm/drm_crtc_helper.c
    </sect2>
    <sect2>
      <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>
 !Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
 !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 -->
--- a/Documentation/DocBook/gadget.tmpl
+++ b/Documentation/DocBook/gadget.tmpl
@@ -671,7 +671,7 @@ than a kernel driver.
 <para>There's a USB Mass Storage class driver, which provides
 a different solution for interoperability with systems such
 as MS-Windows and MacOS.
-That <emphasis>File-backed Storage</emphasis> driver uses a
+That <emphasis>Mass Storage</emphasis> driver uses a
 file or block device as backing store for a drive,
 like the <filename>loop</filename> driver.
 The USB host uses the BBB, CB, or CBI versions of the mass
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -58,6 +58,9 @@
     <sect1><title>String Conversions</title>
 !Elib/vsprintf.c
 !Finclude/linux/kernel.h kstrtol
 !Finclude/linux/kernel.h kstrtoul
 !Elib/kstrtox.c
     </sect1>
     <sect1><title>String Manipulation</title>
 <!-- All functions are exported at now
--- 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
@@ -1184,13 +1184,6 @@ static struct block_device_operations opt_fops = {
     <filename>Documentation/kbuild/kconfig-language.txt</filename>.
    </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
--- 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
--- 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;
--- 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>
--- 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>
--- 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
--- 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>
@@ -2586,6 +2602,13 @@ ioctls.</para>
 	  <para>Vendor and device specific media bus pixel formats.
 	    <xref linkend="v4l2-mbus-vendor-spec-fmts" />.</para>
        </listitem>
        <listitem>
 	  <para>Importing DMABUF file descriptors as a new IO method described
 	  in <xref linkend="dmabuf" />.</para>
        </listitem>
        <listitem>
 	  <para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para>
        </listitem>
      </itemizedlist>
    </section>
--- 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>
--- a/Documentation/DocBook/media/v4l/driver.xml
+++ b/Documentation/DocBook/media/v4l/driver.xml
@@ -116,7 +116,7 @@ my_suspend              (struct pci_dev *               pci_dev,
 	return 0; /* a negative value on error, 0 on success. */
 }
-static void __devexit
+static void
 my_remove               (struct pci_dev *               pci_dev)
 {
 	my_device *my = pci_get_drvdata (pci_dev);
@@ -124,7 +124,7 @@ my_remove               (struct pci_dev *               pci_dev)
 	/* Describe me. */
 }
-static int __devinit
+static int
 my_probe                (struct pci_dev *               pci_dev,
 			 const struct pci_device_id *   pci_id)
 {
@@ -157,7 +157,7 @@ my_pci_driver = {
 	.id_table = my_pci_device_ids,
 	.probe    = my_probe,
-	.remove   = __devexit_p (my_remove),
+	.remove   = my_remove,
 	/* Power management functions. */
 	.suspend  = my_suspend,
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -331,7 +331,7 @@ application until one or more buffers can be dequeued. By default
 outgoing queue. When the <constant>O_NONBLOCK</constant> flag was
 given to the &func-open; function, <constant>VIDIOC_DQBUF</constant>
 returns immediately with an &EAGAIN; when no buffer is available. The
-&func-select; or &func-poll; function are always available.</para>
+&func-select; or &func-poll; functions are always available.</para>
    <para>To start and stop capturing or output applications call the
 &VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note
@@ -472,6 +472,165 @@ rest should be evident.</para>
      </footnote></para>
  </section>
  <section id="dmabuf">
    <title>Streaming I/O (DMA buffer importing)</title>
    <note>
      <title>Experimental</title>
      <para>This is an <link linkend="experimental">experimental</link>
      interface and may change in the future.</para>
    </note>
 <para>The DMABUF framework provides a generic method for sharing buffers
 between multiple devices. Device drivers that support DMABUF can export a DMA
 buffer to userspace as a file descriptor (known as the exporter role), import a
 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 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
 <constant>V4L2_CAP_STREAMING</constant> flag in the
 <structfield>capabilities</structfield> field of &v4l2-capability; returned by
 the &VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through
 DMABUF file descriptors is supported is determined by calling the
 &VIDIOC-REQBUFS; ioctl with the memory type set to
 <constant>V4L2_MEMORY_DMABUF</constant>.</para>
    <para>This I/O method is dedicated to sharing DMA buffers between different
 devices, which may be V4L devices or other video-related devices (e.g. DRM).
 Buffers (planes) are allocated by a driver on behalf of an application. Next,
 these buffers are exported to the application as file descriptors using an API
 which is specific for an allocator driver.  Only such file descriptor are
 exchanged. The descriptors and meta-information are passed in &v4l2-buffer; (or
 in &v4l2-plane; in the multi-planar API case).  The driver must be switched
 into DMABUF I/O mode by calling the &VIDIOC-REQBUFS; with the desired buffer
 type.</para>
    <example>
      <title>Initiating streaming I/O with DMABUF file descriptors</title>
      <programlisting>
 &v4l2-requestbuffers; reqbuf;
 memset(&amp;reqbuf, 0, sizeof (reqbuf));
 reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 reqbuf.memory = V4L2_MEMORY_DMABUF;
 reqbuf.count = 1;
 if (ioctl(fd, &VIDIOC-REQBUFS;, &amp;reqbuf) == -1) {
 	if (errno == EINVAL)
 		printf("Video capturing or DMABUF streaming is not supported\n");
 	else
 		perror("VIDIOC_REQBUFS");
 	exit(EXIT_FAILURE);
 }
      </programlisting>
    </example>
    <para>The buffer (plane) file descriptor is passed on the fly with the
 &VIDIOC-QBUF; ioctl. In case of multiplanar buffers, every plane can be
 associated with a different DMABUF descriptor. Although buffers are commonly
 cycled, applications can pass a different DMABUF descriptor at each
 <constant>VIDIOC_QBUF</constant> call.</para>
    <example>
      <title>Queueing DMABUF using single plane API</title>
      <programlisting>
 int buffer_queue(int v4lfd, int index, int dmafd)
 {
 	&v4l2-buffer; buf;
 	memset(&amp;buf, 0, sizeof buf);
 	buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 	buf.memory = V4L2_MEMORY_DMABUF;
 	buf.index = index;
 	buf.m.fd = dmafd;
 	if (ioctl(v4lfd, &VIDIOC-QBUF;, &amp;buf) == -1) {
 		perror("VIDIOC_QBUF");
 		return -1;
 	}
 	return 0;
 }
      </programlisting>
    </example>
    <example>
      <title>Queueing DMABUF using multi plane API</title>
      <programlisting>
 int buffer_queue_mp(int v4lfd, int index, int dmafd[], int n_planes)
 {
 	&v4l2-buffer; buf;
 	&v4l2-plane; planes[VIDEO_MAX_PLANES];
 	int i;
 	memset(&amp;buf, 0, sizeof buf);
 	buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
 	buf.memory = V4L2_MEMORY_DMABUF;
 	buf.index = index;
 	buf.m.planes = planes;
 	buf.length = n_planes;
 	memset(&amp;planes, 0, sizeof planes);
 	for (i = 0; i &lt; n_planes; ++i)
 		buf.m.planes[i].m.fd = dmafd[i];
 	if (ioctl(v4lfd, &VIDIOC-QBUF;, &amp;buf) == -1) {
 		perror("VIDIOC_QBUF");
 		return -1;
 	}
 	return 0;
 }
      </programlisting>
    </example>
    <para>Captured or displayed buffers are dequeued with the
 &VIDIOC-DQBUF; ioctl. The driver can unlock the buffer at any
 time between the completion of the DMA and this ioctl. The memory is
 also unlocked when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or
 when the device is closed.</para>
    <para>For capturing applications it is customary to enqueue a
 number of empty buffers, to start capturing and enter the read loop.
 Here the application waits until a filled buffer can be dequeued, and
 re-enqueues the buffer when the data is no longer needed. Output
 applications fill and enqueue buffers, when enough buffers are stacked
 up output is started. In the write loop, when the application
 runs out of free buffers it must wait until an empty buffer can be
 dequeued and reused. Two methods exist to suspend execution of the
 application until one or more buffers can be dequeued. By default
 <constant>VIDIOC_DQBUF</constant> blocks when no buffer is in the
 outgoing queue. When the <constant>O_NONBLOCK</constant> flag was
 given to the &func-open; function, <constant>VIDIOC_DQBUF</constant>
 returns immediately with an &EAGAIN; when no buffer is available. The
 &func-select; and &func-poll; functions are always available.</para>
    <para>To start and stop capturing or displaying applications call the
 &VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctls. Note that
 <constant>VIDIOC_STREAMOFF</constant> removes all buffers from both queues and
 unlocks all buffers as a side effect. Since there is no notion of doing
 anything "now" on a multitasking system, if an application needs to synchronize
 with another event it should examine the &v4l2-buffer;
 <structfield>timestamp</structfield> of captured buffers, or set the field
 before enqueuing buffers for output.</para>
    <para>Drivers implementing DMABUF importing I/O must support the
 <constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>,
 <constant>VIDIOC_DQBUF</constant>, <constant>VIDIOC_STREAMON</constant> and
 <constant>VIDIOC_STREAMOFF</constant> ioctls, and the
 <function>select()</function> and <function>poll()</function> functions.</para>
  </section>
  <section id="async">
    <title>Asynchronous I/O</title>
@@ -582,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>
@@ -672,6 +833,14 @@ memory, set by the application. See <xref linkend="userp" /> for details.
 	    in the <structfield>length</structfield> field of this
 	    <structname>v4l2_buffer</structname> structure.</entry>
 	  </row>
 	  <row>
 	    <entry></entry>
 	    <entry>int</entry>
 	    <entry><structfield>fd</structfield></entry>
 	    <entry>For the single-plane API and when
 <structfield>memory</structfield> is <constant>V4L2_MEMORY_DMABUF</constant> this
 is the file descriptor associated with a DMABUF buffer.</entry>
 	  </row>
 	  <row>
 	    <entry>__u32</entry>
 	    <entry><structfield>length</structfield></entry>
@@ -736,13 +905,22 @@ 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
 	      pointer to the memory allocated for this plane by an application.
 	      </entry>
 	  </row>
 	  <row>
 	    <entry></entry>
 	    <entry>int</entry>
 	    <entry><structfield>fd</structfield></entry>
 	    <entry>When the memory type in the containing &v4l2-buffer; is
 		<constant>V4L2_MEMORY_DMABUF</constant>, this is a file
 		descriptor associated with a DMABUF buffer, similar to the
 		<structfield>fd</structfield> field in &v4l2-buffer;.</entry>
 	  </row>
 	  <row>
 	    <entry>__u32</entry>
 	    <entry><structfield>data_offset</structfield></entry>
@@ -923,7 +1101,7 @@ application. Drivers set or clear this flag when the
 	  </row>
 	  <row>
 	    <entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry>
-	    <entry>0x0400</entry>
+	    <entry>0x0800</entry>
 	    <entry>Caches do not have to be invalidated for this buffer.
 Typically applications shall use this flag if the data captured in the buffer
 is not going to be touched by the CPU, instead the buffer will, probably, be
@@ -932,12 +1110,41 @@ passed on to a DMA-capable hardware unit for further processing or output.
 	  </row>
 	  <row>
 	    <entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry>
-	    <entry>0x0800</entry>
+	    <entry>0x1000</entry>
 	    <entry>Caches do not have to be cleaned for this buffer.
 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>
@@ -964,6 +1171,12 @@ pointer</link> I/O.</entry>
 	    <entry>3</entry>
 	    <entry>[to do]</entry>
 	  </row>
 	  <row>
 	    <entry><constant>V4L2_MEMORY_DMABUF</constant></entry>
 	    <entry>4</entry>
 	    <entry>The buffer is used for <link linkend="dmabuf">DMA shared
 buffer</link> I/O.</entry>
 	  </row>
 	</tbody>
      </tgroup>
    </table>
--- 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>
--- a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
+++ 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>
--- a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
+++ 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>
--- 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;
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -139,6 +139,16 @@ structs, ioctls) must be noted in more detail in the history chapter
 (compat.xml), along with the possible impact on existing drivers and
 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>
@@ -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;
@@ -543,6 +553,7 @@ and discussions on the V4L mailing list.</revremark>
    &sub-enuminput;
    &sub-enumoutput;
    &sub-enumstd;
    &sub-expbuf;
    &sub-g-audio;
    &sub-g-audioout;
    &sub-g-crop;
--- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
@@ -6,7 +6,8 @@
  <refnamediv>
    <refname>VIDIOC_CREATE_BUFS</refname>
-    <refpurpose>Create buffers for Memory Mapped or User Pointer I/O</refpurpose>
+    <refpurpose>Create buffers for Memory Mapped or User Pointer or DMA Buffer
    I/O</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
@@ -55,11 +56,11 @@
    </note>
    <para>This ioctl is used to create buffers for <link linkend="mmap">memory
-mapped</link> or <link linkend="userp">user pointer</link>
+mapped</link> or <link linkend="userp">user pointer</link> or <link
-I/O. It can be used as an alternative or in addition to the
+linkend="dmabuf">DMA buffer</link> I/O. It can be used as an alternative or in
-<constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter control over buffers
+addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter
-is required. This ioctl can be called multiple times to create buffers of
+control over buffers is required. This ioctl can be called multiple times to
-different sizes.</para>
+create buffers of different sizes.</para>
    <para>To allocate device buffers applications initialize relevant fields of
 the <structname>v4l2_create_buffers</structname> structure. They set the
@@ -109,7 +110,8 @@ information.</para>
 	    <entry>__u32</entry>
 	    <entry><structfield>memory</structfield></entry>
 	    <entry>Applications set this field to
-<constant>V4L2_MEMORY_MMAP</constant> or
+<constant>V4L2_MEMORY_MMAP</constant>,
 <constant>V4L2_MEMORY_DMABUF</constant> or
 <constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory"
 /></entry>
 	  </row>
--- 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>
--- a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
@@ -0,0 +1,208 @@
 <refentry id="vidioc-expbuf">
  <refmeta>
    <refentrytitle>ioctl VIDIOC_EXPBUF</refentrytitle>
    &manvol;
  </refmeta>
  <refnamediv>
    <refname>VIDIOC_EXPBUF</refname>
    <refpurpose>Export a buffer as a DMABUF file descriptor.</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <funcsynopsis>
      <funcprototype>
 	<funcdef>int <function>ioctl</function></funcdef>
 	<paramdef>int <parameter>fd</parameter></paramdef>
 	<paramdef>int <parameter>request</parameter></paramdef>
 	<paramdef>struct v4l2_exportbuffer *<parameter>argp</parameter></paramdef>
      </funcprototype>
    </funcsynopsis>
  </refsynopsisdiv>
  <refsect1>
    <title>Arguments</title>
    <variablelist>
      <varlistentry>
 	<term><parameter>fd</parameter></term>
 	<listitem>
 	  <para>&fd;</para>
 	</listitem>
      </varlistentry>
      <varlistentry>
 	<term><parameter>request</parameter></term>
 	<listitem>
 	  <para>VIDIOC_EXPBUF</para>
 	</listitem>
      </varlistentry>
      <varlistentry>
 	<term><parameter>argp</parameter></term>
 	<listitem>
 	  <para></para>
 	</listitem>
      </varlistentry>
    </variablelist>
  </refsect1>
  <refsect1>
    <title>Description</title>
    <note>
      <title>Experimental</title>
      <para>This is an <link linkend="experimental"> experimental </link>
      interface and may change in the future.</para>
    </note>
 <para>This ioctl is an extension to the <link linkend="mmap">memory
 mapping</link> I/O method, therefore it is available only for
 <constant>V4L2_MEMORY_MMAP</constant> buffers.  It can be used to export a
 buffer as a DMABUF file at any time after buffers have been allocated with the
 &VIDIOC-REQBUFS; ioctl.</para>
 <para> To export a buffer, applications fill &v4l2-exportbuffer;.  The
 <structfield> type </structfield> field is set to the same buffer type as was
 previously used with  &v4l2-requestbuffers;<structfield> type </structfield>.
 Applications must also set the <structfield> index </structfield> field. Valid
 index numbers range from zero to the number of buffers allocated with
 &VIDIOC-REQBUFS; (&v4l2-requestbuffers;<structfield> count </structfield>)
 minus one.  For the multi-planar API, applications set the <structfield> plane
 </structfield> field to the index of the plane to be exported. Valid planes
 range from zero to the maximal number of valid planes for the currently active
 format. For the single-planar API, applications must set <structfield> plane
 </structfield> to zero.  Additional flags may be posted in the <structfield>
 flags </structfield> field.  Refer to a manual for open() for details.
 Currently only O_CLOEXEC is supported.  All other fields must be set to zero.
 In the case of multi-planar API, every plane is exported separately using
 multiple <constant> VIDIOC_EXPBUF </constant> calls. </para>
 <para> After calling <constant>VIDIOC_EXPBUF</constant> the <structfield> fd
 </structfield> field will be set by a driver.  This is a DMABUF file
 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>
    <title>Examples</title>
    <example>
      <title>Exporting a buffer.</title>
      <programlisting>
 int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
 {
 	&v4l2-exportbuffer; expbuf;
 	memset(&amp;expbuf, 0, sizeof(expbuf));
 	expbuf.type = bt;
 	expbuf.index = index;
 	if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &amp;expbuf) == -1) {
 		perror("VIDIOC_EXPBUF");
 		return -1;
 	}
 	*dmafd = expbuf.fd;
 	return 0;
 }
      </programlisting>
    </example>
    <example>
      <title>Exporting a buffer using the multi-planar API.</title>
      <programlisting>
 int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
 	int dmafd[], int n_planes)
 {
 	int i;
 	for (i = 0; i &lt; n_planes; ++i) {
 		&v4l2-exportbuffer; expbuf;
 		memset(&amp;expbuf, 0, sizeof(expbuf));
 		expbuf.type = bt;
 		expbuf.index = index;
 		expbuf.plane = i;
 		if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &amp;expbuf) == -1) {
 			perror("VIDIOC_EXPBUF");
 			while (i)
 				close(dmafd[--i]);
 			return -1;
 		}
 		dmafd[i] = expbuf.fd;
 	}
 	return 0;
 }
      </programlisting>
    </example>
    <table pgwide="1" frame="none" id="v4l2-exportbuffer">
      <title>struct <structname>v4l2_exportbuffer</structname></title>
      <tgroup cols="3">
 	&cs-str;
 	<tbody valign="top">
 	  <row>
 	    <entry>__u32</entry>
 	    <entry><structfield>type</structfield></entry>
 	    <entry>Type of the buffer, same as &v4l2-format;
 <structfield>type</structfield> or &v4l2-requestbuffers;
 <structfield>type</structfield>, set by the application. See <xref
 linkend="v4l2-buf-type" /></entry>
 	  </row>
 	  <row>
 	    <entry>__u32</entry>
 	    <entry><structfield>index</structfield></entry>
 	    <entry>Number of the buffer, set by the application. This field is
 only used for <link linkend="mmap">memory mapping</link> I/O and can range from
 zero to the number of buffers allocated with the &VIDIOC-REQBUFS; and/or
 &VIDIOC-CREATE-BUFS; ioctls. </entry>
 	  </row>
 	  <row>
 	    <entry>__u32</entry>
 	    <entry><structfield>plane</structfield></entry>
 	    <entry>Index of the plane to be exported when using the
 multi-planar API. Otherwise this value must be set to zero. </entry>
 	  </row>
 	  <row>
 	    <entry>__u32</entry>
 	    <entry><structfield>flags</structfield></entry>
 	    <entry>Flags for the newly created file, currently only <constant>
 O_CLOEXEC </constant> is supported, refer to the manual of open() for more
 details.</entry>
 	  </row>
 	  <row>
 	    <entry>__s32</entry>
 	    <entry><structfield>fd</structfield></entry>
 	    <entry>The DMABUF file descriptor associated with a buffer. Set by
 		the driver.</entry>
 	  </row>
 	  <row>
 	    <entry>__u32</entry>
 	    <entry><structfield>reserved[11]</structfield></entry>
 	    <entry>Reserved field for future use. Must be set to zero.</entry>
 	  </row>
 	</tbody>
      </tgroup>
    </table>
  </refsect1>
  <refsect1>
    &return-value;
    <variablelist>
      <varlistentry>
 	<term><errorcode>EINVAL</errorcode></term>
 	<listitem>
 	  <para>A queue is not in MMAP mode or DMABUF exporting is not
 supported or <structfield> flags </structfield> or <structfield> type
 </structfield> or <structfield> index </structfield> or <structfield> plane
 </structfield> fields are invalid.</para>
 	</listitem>
      </varlistentry>
    </variablelist>
  </refsect1>
 </refentry>
--- 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>
--- 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>
--- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
@@ -109,6 +109,23 @@ they cannot be swapped out to disk. Buffers remain locked until
 dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is
 called, or until the device is closed.</para>
    <para>To enqueue a <link linkend="dmabuf">DMABUF</link> buffer applications
 set the <structfield>memory</structfield> field to
 <constant>V4L2_MEMORY_DMABUF</constant> and the <structfield>m.fd</structfield>
 field to a file descriptor associated with a DMABUF buffer. When the
 multi-planar API is used the <structfield>m.fd</structfield> fields of the
 passed array of &v4l2-plane; have to be used instead. When
 <constant>VIDIOC_QBUF</constant> is called with a pointer to this structure the
 driver sets the <constant>V4L2_BUF_FLAG_QUEUED</constant> flag and clears the
 <constant>V4L2_BUF_FLAG_MAPPED</constant> and
 <constant>V4L2_BUF_FLAG_DONE</constant> flags in the
 <structfield>flags</structfield> field, or it returns an error code.  This
 ioctl locks the buffer. Locking a buffer means passing it to a driver for a
 hardware access (usually DMA).  If an application accesses (reads/writes) a
 locked buffer then the result is undefined.  Buffers remain locked until
 dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is called, or
 until the device is closed.</para>
    <para>Applications call the <constant>VIDIOC_DQBUF</constant>
 ioctl to dequeue a filled (capturing) or displayed (output) buffer
 from the driver's outgoing queue. They just set the
--- 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
--- a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml
@@ -48,28 +48,30 @@
  <refsect1>
    <title>Description</title>
-    <para>This ioctl is used to initiate <link linkend="mmap">memory
+<para>This ioctl is used to initiate <link linkend="mmap">memory mapped</link>,
-mapped</link> or <link linkend="userp">user pointer</link>
+<link linkend="userp">user pointer</link> or <link
-I/O. Memory mapped buffers are located in device memory and must be
+linkend="dmabuf">DMABUF</link> based I/O.  Memory mapped buffers are located in
-allocated with this ioctl before they can be mapped into the
+device memory and must be allocated with this ioctl before they can be mapped
-application's address space. User buffers are allocated by
+into the application's address space. User buffers are allocated by
-applications themselves, and this ioctl is merely used to switch the
+applications themselves, and this ioctl is merely used to switch the driver
-driver into user pointer I/O mode and to setup some internal structures.</para>
+into user pointer I/O mode and to setup some internal structures.
 Similarly, DMABUF buffers are allocated by applications through a device
 driver, and this ioctl only configures the driver into DMABUF I/O mode without
 performing any direct allocation.</para>
-    <para>To allocate device buffers applications initialize all
+    <para>To allocate device buffers applications initialize all fields of the
-fields of the <structname>v4l2_requestbuffers</structname> structure.
+<structname>v4l2_requestbuffers</structname> structure.  They set the
-They set the <structfield>type</structfield> field to the respective
+<structfield>type</structfield> field to the respective stream or buffer type,
-stream or buffer type, the <structfield>count</structfield> field to
+the <structfield>count</structfield> field to the desired number of buffers,
-the desired number of buffers, <structfield>memory</structfield>
+<structfield>memory</structfield> must be set to the requested I/O method and
-must be set to the requested I/O method and the <structfield>reserved</structfield> array
+the <structfield>reserved</structfield> array must be zeroed. When the ioctl is
-must be zeroed. When the ioctl
+called with a pointer to this structure the driver will attempt to allocate the
-is called with a pointer to this structure the driver will attempt to allocate
+requested number of buffers and it stores the actual number allocated in the
-the requested number of buffers and it stores the actual number
+<structfield>count</structfield> field. It can be smaller than the number
-allocated in the <structfield>count</structfield> field. It can be
+requested, even zero, when the driver runs out of free memory. A larger number
-smaller than the number requested, even zero, when the driver runs out
+is also possible when the driver requires more buffers to function correctly.
-of free memory. A larger number is also possible when the driver requires
+For example video output requires at least two buffers, one displayed and one
-more buffers to function correctly. For example video output requires at least two buffers,
+filled by the application.</para>
 one displayed and one filled by the application.</para>
    <para>When the I/O method is not supported the ioctl
 returns an &EINVAL;.</para>
@@ -102,7 +104,8 @@ as the &v4l2-format; <structfield>type</structfield> field. See <xref
 	    <entry>__u32</entry>
 	    <entry><structfield>memory</structfield></entry>
 	    <entry>Applications set this field to
-<constant>V4L2_MEMORY_MMAP</constant> or
+<constant>V4L2_MEMORY_MMAP</constant>,
 <constant>V4L2_MEMORY_DMABUF</constant> or
 <constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory"
 />.</entry>
 	  </row>
--- 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">
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -719,6 +719,62 @@ framework to set up sysfs files for this region. Simply leave it alone.
 	</para>
 </sect1>
 <sect1 id="using uio_dmem_genirq">
 <title>Using uio_dmem_genirq for platform devices</title>
 	<para>
 	In addition to statically allocated memory ranges, they may also be
 	a desire to use dynamically allocated regions in a user space driver.
 	In particular, being able to access memory made available through the
 	dma-mapping API, may be particularly useful.  The
 	<varname>uio_dmem_genirq</varname> driver provides a way to accomplish
 	this.
 	</para>
 	<para>
 	This driver is used in a similar manner to the
 	<varname>"uio_pdrv_genirq"</varname> driver with respect to interrupt
 	configuration and handling.
 	</para>
 	<para>
 	Set the <varname>.name</varname> element of
 	<varname>struct platform_device</varname> to
 	<varname>"uio_dmem_genirq"</varname> to use this driver.
 	</para>
 	<para>
 	When using this driver, fill in the <varname>.platform_data</varname>
 	element of <varname>struct platform_device</varname>, which is of type
 	<varname>struct uio_dmem_genirq_pdata</varname> and which contains the
 	following elements:
 	</para>
 	<itemizedlist>
 	<listitem><varname>struct uio_info uioinfo</varname>: The same
 	structure used as the  <varname>uio_pdrv_genirq</varname> platform
 	data</listitem>
 	<listitem><varname>unsigned int *dynamic_region_sizes</varname>:
 	Pointer to list of sizes of dynamic memory regions to be mapped into
 	user space.
 	</listitem>
 	<listitem><varname>unsigned int num_dynamic_regions</varname>:
 	Number of elements in <varname>dynamic_region_sizes</varname> array.
 	</listitem>
 	</itemizedlist>
 	<para>
 	The dynamic regions defined in the platform data will be appended to
 	the <varname> mem[] </varname> array after the platform device
 	resources, which implies that the total number of static and dynamic
 	memory regions cannot exceed <varname>MAX_UIO_MAPS</varname>.
 	</para>
 	<para>
 	The dynamic memory regions will be allocated when the UIO device file,
 	<varname>/dev/uioX</varname> is opened.
 	Simiar to static memory resources, the memory region information for
 	dynamic regions is then visible via sysfs at
 	<varname>/sys/class/uio/uioX/maps/mapY/*</varname>.
 	The dynmaic memory regions will be freed when the UIO device file is
 	closed. When no processes are holding the device file open, the address
 	returned to userspace is ~0.
 	</para>
 </sect1>
 </chapter>
 <chapter id="userspace_driver" xreflabel="Writing a driver in user space">
@@ -928,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;
 	}
--- a/Documentation/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl
@@ -433,9 +433,9 @@
  /* chip-specific constructor
   * (see "Management of Cards and Components")
   */
-  static int __devinit snd_mychip_create(struct snd_card *card,
+  static int snd_mychip_create(struct snd_card *card,
-                                         struct pci_dev *pci,
+                               struct pci_dev *pci,
-                                         struct mychip **rchip)
+                               struct mychip **rchip)
  {
          struct mychip *chip;
          int err;
@@ -475,8 +475,8 @@
  }
  /* constructor -- see "Constructor" sub-section */
-  static int __devinit snd_mychip_probe(struct pci_dev *pci,
+  static int snd_mychip_probe(struct pci_dev *pci,
-                               const struct pci_device_id *pci_id)
+                              const struct pci_device_id *pci_id)
  {
          static int dev;
          struct snd_card *card;
@@ -526,7 +526,7 @@
  }
  /* destructor -- see the "Destructor" sub-section */
-  static void __devexit snd_mychip_remove(struct pci_dev *pci)
+  static void snd_mychip_remove(struct pci_dev *pci)
  {
          snd_card_free(pci_get_drvdata(pci));
          pci_set_drvdata(pci, NULL);
@@ -542,9 +542,8 @@
      <para>
        The real constructor of PCI drivers is the <function>probe</function> callback.
      The <function>probe</function> callback and other component-constructors which are called
-      from the <function>probe</function> callback should be defined with
+      from the <function>probe</function> callback cannot be used with
-      the <parameter>__devinit</parameter> prefix. You 
+      the <parameter>__init</parameter> prefix
      cannot use the <parameter>__init</parameter> prefix for them,
      because any PCI device could be a hotplug device. 
      </para>
@@ -728,7 +727,7 @@
        <informalexample>
          <programlisting>
 <![CDATA[
-  static void __devexit snd_mychip_remove(struct pci_dev *pci)
+  static void snd_mychip_remove(struct pci_dev *pci)
  {
          snd_card_free(pci_get_drvdata(pci));
          pci_set_drvdata(pci, NULL);
@@ -872,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>
@@ -1058,14 +1056,6 @@
      components are released automatically by this call. 
      </para>
      <para>
        As further notes, the destructors (both
      <function>snd_mychip_dev_free</function> and
      <function>snd_mychip_free</function>) cannot be defined with
      the <parameter>__devexit</parameter> prefix, because they may be
      called from the constructor, too, at the false path. 
      </para>
      <para>
      For a device which allows hotplugging, you can use
      <function>snd_card_free_when_closed</function>.  This one will
@@ -1120,9 +1110,9 @@
  }
  /* chip-specific constructor */
-  static int __devinit snd_mychip_create(struct snd_card *card,
+  static int snd_mychip_create(struct snd_card *card,
-                                         struct pci_dev *pci,
+                               struct pci_dev *pci,
-                                         struct mychip **rchip)
+                               struct mychip **rchip)
  {
          struct mychip *chip;
          int err;
@@ -1200,7 +1190,7 @@
          .name = KBUILD_MODNAME,
          .id_table = snd_mychip_ids,
          .probe = snd_mychip_probe,
-          .remove = __devexit_p(snd_mychip_remove),
+          .remove = snd_mychip_remove,
  };
  /* module initialization */
@@ -1464,11 +1454,6 @@
        </informalexample>
      </para>
      <para>
      Again, remember that you cannot
      use the <parameter>__devexit</parameter> prefix for this destructor. 
      </para>
      <para>
      We didn't implement the hardware disabling part in the above.
      If you need to do this, please note that the destructor may be
@@ -1619,7 +1604,7 @@
          .name = KBUILD_MODNAME,
          .id_table = snd_mychip_ids,
          .probe = snd_mychip_probe,
-          .remove = __devexit_p(snd_mychip_remove),
+          .remove = snd_mychip_remove,
  };
 ]]>
          </programlisting>
@@ -1630,11 +1615,7 @@
        The <structfield>probe</structfield> and
      <structfield>remove</structfield> functions have already
      been defined in the previous sections.
-      The <structfield>remove</structfield> function should
+      The <structfield>name</structfield>
      be defined with the 
      <function>__devexit_p()</function> macro, so that it's not
      defined for built-in (and non-hot-pluggable) case. The
      <structfield>name</structfield> 
      field is the name string of this device. Note that you must not
      use a slash <quote>/</quote> in this string. 
      </para>
@@ -1665,9 +1646,7 @@
      <para>
        Note that these module entries are tagged with
      <parameter>__init</parameter> and 
-      <parameter>__exit</parameter> prefixes, not
+      <parameter>__exit</parameter> prefixes.
      <parameter>__devinit</parameter> nor
      <parameter>__devexit</parameter>.
      </para>
      <para>
@@ -1918,7 +1897,7 @@
   */
  /* create a pcm device */
-  static int __devinit snd_mychip_new_pcm(struct mychip *chip)
+  static int snd_mychip_new_pcm(struct mychip *chip)
  {
          struct snd_pcm *pcm;
          int err;
@@ -1957,7 +1936,7 @@
        <informalexample>
          <programlisting>
 <![CDATA[
-  static int __devinit snd_mychip_new_pcm(struct mychip *chip)
+  static int snd_mychip_new_pcm(struct mychip *chip)
  {
          struct snd_pcm *pcm;
          int err;
@@ -2124,7 +2103,7 @@
          ....
  }
-  static int __devinit snd_mychip_new_pcm(struct mychip *chip)
+  static int snd_mychip_new_pcm(struct mychip *chip)
  {
          struct snd_pcm *pcm;
          ....
@@ -2324,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
@@ -2918,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. 
@@ -3105,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
@@ -3270,49 +3249,6 @@ struct _snd_pcm_runtime {
        <example>
 	  <title>Example of Hardware Constraints for Channels</title>
 	  <programlisting>
 <![CDATA[
  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);
          struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
          struct snd_mask fmt;
          snd_mask_any(&fmt);    /* Init the struct */
          if (c->min < 2) {
                  fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
                  return snd_mask_refine(f, &fmt);
          }
          return 0;
  }
 ]]>
          </programlisting>
        </example>
      </para>
      <para>
        Then you need to call this function to add your rule:
       <informalexample>
 	 <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,
                      -1);
 ]]>
          </programlisting>
        </informalexample>
      </para>
      <para>
        The rule function is called when an application sets the number of
        channels. But an application can set the format before the number of
        channels. Thus you also need to define the inverse rule:
       <example>
 	 <title>Example of Hardware Constraints for Channels</title>
 	 <programlisting>
 <![CDATA[
  static int hw_rule_channels_by_format(struct snd_pcm_hw_params *params,
                                        struct snd_pcm_hw_rule *rule)
@@ -3334,6 +3270,50 @@ struct _snd_pcm_runtime {
          </programlisting>
        </example>
      </para>
      <para>
        Then you need to call this function to add your rule:
       <informalexample>
 	 <programlisting>
 <![CDATA[
  snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
                      hw_rule_channels_by_format, NULL,
                      SNDRV_PCM_HW_PARAM_FORMAT, -1);
 ]]>
          </programlisting>
        </informalexample>
      </para>
      <para>
        The rule function is called when an application sets the PCM
 	format, and it refines the number of channels accordingly.
        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 Formats</title>
 	 <programlisting>
 <![CDATA[
  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);
          struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
          struct snd_mask fmt;
          snd_mask_any(&fmt);    /* Init the struct */
          if (c->min < 2) {
                  fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
                  return snd_mask_refine(f, &fmt);
          }
          return 0;
  }
 ]]>
          </programlisting>
        </example>
      </para>
      <para>
      ...and in the open callback:
@@ -3341,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>
@@ -3399,7 +3379,7 @@ struct _snd_pcm_runtime {
 	  <title>Definition of a Control</title>
          <programlisting>
 <![CDATA[
-  static struct snd_kcontrol_new my_control __devinitdata = {
+  static struct snd_kcontrol_new my_control = {
          .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
          .name = "PCM Playback Switch",
          .index = 0,
@@ -3414,13 +3394,6 @@ struct _snd_pcm_runtime {
        </example>
      </para>
      <para>
        Most likely the control is created via
      <function>snd_ctl_new1()</function>, and in such a case, you can
      add the <parameter>__devinitdata</parameter> prefix to the
      definition as above. 
      </para>
      <para>
        The <structfield>iface</structfield> field specifies the control
      type, <constant>SNDRV_CTL_ELEM_IFACE_XXX</constant>, which
@@ -3847,10 +3820,8 @@ struct _snd_pcm_runtime {
      <para>
        <function>snd_ctl_new1()</function> allocates a new
-      <structname>snd_kcontrol</structname> instance (that's why the definition
+      <structname>snd_kcontrol</structname> instance,
-      of <parameter>my_control</parameter> can be with
+      and <function>snd_ctl_add</function> assigns the given
      the <parameter>__devinitdata</parameter> 
      prefix), and <function>snd_ctl_add</function> assigns the given
      control component to the card. 
      </para>
    </section>
@@ -3896,7 +3867,7 @@ struct _snd_pcm_runtime {
 <![CDATA[
  static DECLARE_TLV_DB_SCALE(db_scale_my_control, -4050, 150, 0);
-  static struct snd_kcontrol_new my_control __devinitdata = {
+  static struct snd_kcontrol_new my_control = {
          ...
          .access = SNDRV_CTL_ELEM_ACCESS_READWRITE |
                    SNDRV_CTL_ELEM_ACCESS_TLV_READ,
@@ -5761,8 +5732,8 @@ struct _snd_pcm_runtime {
      <informalexample>
        <programlisting>
 <![CDATA[
-  static int __devinit snd_mychip_probe(struct pci_dev *pci,
+  static int snd_mychip_probe(struct pci_dev *pci,
-                               const struct pci_device_id *pci_id)
+                              const struct pci_device_id *pci_id)
  {
          ....
          struct snd_card *card;
@@ -5787,8 +5758,8 @@ struct _snd_pcm_runtime {
      <informalexample>
        <programlisting>
 <![CDATA[
-  static int __devinit snd_mychip_probe(struct pci_dev *pci,
+  static int snd_mychip_probe(struct pci_dev *pci,
-                               const struct pci_device_id *pci_id)
+                              const struct pci_device_id *pci_id)
  {
          ....
          struct snd_card *card;
@@ -5825,7 +5796,7 @@ struct _snd_pcm_runtime {
          .name = KBUILD_MODNAME,
          .id_table = snd_my_ids,
          .probe = snd_my_probe,
-          .remove = __devexit_p(snd_my_remove),
+          .remove = snd_my_remove,
  #ifdef CONFIG_PM
          .suspend = snd_my_suspend,
          .resume = snd_my_resume,
--- 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
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -462,7 +462,7 @@ Differences between the kernel community and corporate structures
 The kernel community works differently than most traditional corporate
 development environments.  Here are a list of things that you can try to
-do to try to avoid problems:
+do to avoid problems:
  Good things to say regarding your proposed changes:
    - "This solves multiple problems."
    - "This deletes 2000 lines of code."
--- a/Documentation/IPMI.txt
+++ b/Documentation/IPMI.txt
@@ -348,34 +348,40 @@ You can change this at module load time (for a module) with:
  modprobe ipmi_si.o type=<type1>,<type2>....
       ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
-       irqs=<irq1>,<irq2>... trydefaults=[0|1]
+       irqs=<irq1>,<irq2>...
       regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
       regshifts=<shift1>,<shift2>,...
       slave_addrs=<addr1>,<addr2>,...
       force_kipmid=<enable1>,<enable2>,...
       kipmid_max_busy_us=<ustime1>,<ustime2>,...
       unload_when_empty=[0|1]
       trydefaults=[0|1] trydmi=[0|1] tryacpi=[0|1]
       tryplatform=[0|1] trypci=[0|1]
-Each of these except si_trydefaults is a list, the first item for the
+Each of these except try... items is a list, the first item for the
 first interface, second item for the second interface, etc.
 The si_type may be either "kcs", "smic", or "bt".  If you leave it blank, it
 defaults to "kcs".
-If you specify si_addrs as non-zero for an interface, the driver will
+If you specify addrs as non-zero for an interface, the driver will
 use the memory address given as the address of the device.  This
 overrides si_ports.
-If you specify si_ports as non-zero for an interface, the driver will
+If you specify ports as non-zero for an interface, the driver will
 use the I/O port given as the device address.
-If you specify si_irqs as non-zero for an interface, the driver will
+If you specify irqs as non-zero for an interface, the driver will
 attempt to use the given interrupt for the device.
-si_trydefaults sets whether the standard IPMI interface at 0xca2 and
+trydefaults sets whether the standard IPMI interface at 0xca2 and
 any interfaces specified by ACPE are tried.  By default, the driver
 tries it, set this value to zero to turn this off.
 The other try... items disable discovery by their corresponding
 names.  These are all enabled by default, set them to zero to disable
 them.  The tryplatform disables openfirmware.
 The next three parameters have to do with register layout.  The
 registers used by the interfaces may not appear at successive
 locations and they may not be in 8-bit registers.  These parameters
--- a/Documentation/IRQ-domain.txt
+++ b/Documentation/IRQ-domain.txt
@@ -7,6 +7,21 @@ systems with multiple interrupt controllers the kernel must ensure
 that each one gets assigned non-overlapping allocations of Linux
 IRQ numbers.
 The number of interrupt controllers registered as unique irqchips
 show a rising tendency: for example subdrivers of different kinds
 such as GPIO controllers avoid reimplementing identical callback
 mechanisms as the IRQ core system by modelling their interrupt
 handlers as irqchips, i.e. in effect cascading interrupt controllers.
 Here the interrupt number loose all kind of correspondence to
 hardware interrupt numbers: whereas in the past, IRQ numbers could
 be chosen so they matched the hardware IRQ line into the root
 interrupt controller (i.e. the component actually fireing the
 interrupt line to the CPU) nowadays this number is just a number.
 For this reason we need a mechanism to separate controller-local
 interrupt numbers, called hardware irq's, from Linux IRQ numbers.
 The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of
 irq numbers, but they don't provide any support for reverse mapping of
 the controller-local IRQ (hwirq) number into the Linux IRQ number
@@ -40,6 +55,10 @@ required hardware setup.
 When an interrupt is received, irq_find_mapping() function should
 be used to find the Linux IRQ number from the hwirq number.
 The irq_create_mapping() function must be called *atleast once*
 before any call to irq_find_mapping(), lest the descriptor will not
 be allocated.
 If the driver has the Linux IRQ number or the irq_data pointer, and
 needs to know the associated hwirq number (such as in the irq_chip
 callbacks) then it can be directly obtained from irq_data->hwirq.
@@ -119,4 +138,17 @@ numbers.
 Most users of legacy mappings should use irq_domain_add_simple() which
 will use a legacy domain only if an IRQ range is supplied by the
-system and will otherwise use a linear domain mapping.
+system and will otherwise use a linear domain mapping. The semantics
 of this call are such that if an IRQ range is specified then
 descriptors will be allocated on-the-fly for it, and if no range is
 specified it will fall through to irq_domain_add_linear() which meand
 *no* irq descriptors will be allocated.
 A typical use case for simple domains is where an irqchip provider
 is supporting both dynamic and static IRQ assignments.
 In order to avoid ending up in a situation where a linear domain is
 used and no descriptor gets allocated it is very important to make sure
 that the driver using the simple domain call irq_create_mapping()
 before any irq_find_mapping() since the latter will actually work
 for the static IRQ assignment case.
--- 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().
--- a/Documentation/PCI/pci-iov-howto.txt
+++ b/Documentation/PCI/pci-iov-howto.txt
@@ -2,6 +2,9 @@
 		Copyright (C) 2009 Intel Corporation
 		    Yu Zhao <yu.zhao@intel.com>
 		Update: November 2012
 			-- sysfs-based SRIOV enable-/disable-ment
 		Donald Dutile <ddutile@redhat.com>
 1. Overview
@@ -24,10 +27,21 @@ real existing PCI device.
 2.1 How can I enable SR-IOV capability
-The device driver (PF driver) will control the enabling and disabling
+Multiple methods are available for SR-IOV enablement.
-of the capability via API provided by SR-IOV core. If the hardware
+In the first method, the device driver (PF driver) will control the
-has SR-IOV capability, loading its PF driver would enable it and all
+enabling and disabling of the capability via API provided by SR-IOV core.
-VFs associated with the PF.
+If the hardware has SR-IOV capability, loading its PF driver would
 enable it and all VFs associated with the PF.  Some PF drivers require
 a module parameter to be set to determine the number of VFs to enable.
 In the second method, a write to the sysfs file sriov_numvfs will
 enable and disable the VFs associated with a PCIe PF.  This method
 enables per-PF, VF enable/disable values versus the first method,
 which applies to all PFs of the same device.  Additionally, the
 PCI SRIOV core support ensures that enable/disable operations are
 valid to reduce duplication in multiple drivers for the same
 checks, e.g., check numvfs == 0 if enabling VFs, ensure
 numvfs <= totalvfs.
 The second method is the recommended method for new/future VF devices.
 2.2 How can I use the Virtual Functions
@@ -40,20 +54,29 @@ requires device driver that is same as a normal PCI device's.
 3.1 SR-IOV API
 To enable SR-IOV capability:
 (a) For the first method, in the driver:
 	int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn);
 	'nr_virtfn' is number of VFs to be enabled.
 (b) For the second method, from sysfs:
 	echo 'nr_virtfn' > \
        /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs
 To disable SR-IOV capability:
 (a) For the first method, in the driver:
 	void pci_disable_sriov(struct pci_dev *dev);
 (b) For the second method, from sysfs:
 	echo  0 > \
        /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs
 To notify SR-IOV core of Virtual Function Migration:
 (a) In the driver:
 	irqreturn_t pci_sriov_migration(struct pci_dev *dev);
 3.2 Usage example
 Following piece of code illustrates the usage of the SR-IOV API.
-static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
+static int dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
 	pci_enable_sriov(dev, NR_VIRTFN);
@@ -62,7 +85,7 @@ static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *
 	return 0;
 }
-static void __devexit dev_remove(struct pci_dev *dev)
+static void dev_remove(struct pci_dev *dev)
 {
 	pci_disable_sriov(dev);
@@ -88,12 +111,29 @@ static void dev_shutdown(struct pci_dev *dev)
 	...
 }
 static int dev_sriov_configure(struct pci_dev *dev, int numvfs)
 {
 	if (numvfs > 0) {
 		...
 		pci_enable_sriov(dev, numvfs);
 		...
 		return numvfs;
 	}
 	if (numvfs == 0) {
 		....
 		pci_disable_sriov(dev);
 		...
 		return 0;
 	}
 }
 static struct pci_driver dev_driver = {
 	.name =		"SR-IOV Physical Function driver",
 	.id_table =	dev_id_table,
 	.probe =	dev_probe,
-	.remove =	__devexit_p(dev_remove),
+	.remove =	dev_remove,
 	.suspend =	dev_suspend,
 	.resume =	dev_resume,
 	.shutdown =	dev_shutdown,
 	.sriov_configure = dev_sriov_configure,
 };
--- a/Documentation/PCI/pci.txt
+++ b/Documentation/PCI/pci.txt
@@ -183,12 +183,6 @@ Please mark the initialization and cleanup functions where appropriate
 			initializes.
 	__exit		Exit code. Ignored for non-modular drivers.
 	__devinit	Device initialization code.
 			Identical to __init if the kernel is not compiled
 			with CONFIG_HOTPLUG, normal function otherwise.
 	__devexit	The same for __exit.
 Tips on when/where to use the above attributes:
 	o The module_init()/module_exit() functions (and all
 	  initialization functions called _only_ from these)
@@ -196,20 +190,6 @@ Tips on when/where to use the above attributes:
 	o Do not mark the struct pci_driver.
 	o The ID table array should be marked __devinitconst; this is done
 	  automatically if the table is declared with DEFINE_PCI_DEVICE_TABLE().
 	o The probe() and remove() functions should be marked __devinit
 	  and __devexit respectively.  All initialization functions
 	  exclusively called by the probe() routine, can be marked __devinit.
 	  Ditto for remove() and __devexit.
 	o If mydriver_remove() is marked with __devexit(), then all address
 	  references to mydriver_remove must use __devexit_p(mydriver_remove)
 	  (in the struct pci_driver declaration for example).
 	  __devexit_p() will generate the function name _or_ NULL if the
 	  function will be discarded.  For an example, see drivers/net/tg3.c.
 	o Do NOT mark a function if you are not sure which mark to use.
 	  Better to not mark the function than mark the function wrong.
--- a/Documentation/RCU/RTFP.txt
+++ b/Documentation/RCU/RTFP.txt
@@ -186,7 +186,7 @@ Bibtex Entries
@article{Kung80
 ,author="H. T. Kung and Q. Lehman"
-,title="Concurrent Maintenance of Binary Search Trees"
+,title="Concurrent Manipulation of Binary Search Trees"
 ,Year="1980"
 ,Month="September"
 ,journal="ACM Transactions on Database Systems"
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -271,15 +271,14 @@ over a rather long period of time, but improvements are always welcome!
 	The same cautions apply to call_rcu_bh() and call_rcu_sched().
 9.	All RCU list-traversal primitives, which include
-	rcu_dereference(), list_for_each_entry_rcu(),
+	rcu_dereference(), list_for_each_entry_rcu(), and
-	list_for_each_continue_rcu(), and list_for_each_safe_rcu(),
+	list_for_each_safe_rcu(), must be either within an RCU read-side
-	must be either within an RCU read-side critical section or
+	critical section or must be protected by appropriate update-side
-	must be protected by appropriate update-side locks.  RCU
+	locks.	RCU read-side critical sections are delimited by
-	read-side critical sections are delimited by rcu_read_lock()
+	rcu_read_lock() and rcu_read_unlock(), or by similar primitives
-	and rcu_read_unlock(), or by similar primitives such as
+	such as rcu_read_lock_bh() and rcu_read_unlock_bh(), in which
-	rcu_read_lock_bh() and rcu_read_unlock_bh(), in which case
+	case the matching rcu_dereference() primitive must be used in
-	the matching rcu_dereference() primitive must be used in order
+	order to keep lockdep happy, in this case, rcu_dereference_bh().
 	to keep lockdep happy, in this case, rcu_dereference_bh().
 	The reason that it is permissible to use RCU list-traversal
 	primitives when the update-side lock is held is that doing so
--- a/Documentation/RCU/listRCU.txt
+++ b/Documentation/RCU/listRCU.txt
@@ -205,7 +205,7 @@ RCU ("read-copy update") its name.  The RCU code is as follows:
 				audit_copy_rule(&ne->rule, &e->rule);
 				ne->rule.action = newaction;
 				ne->rule.file_count = newfield_count;
-				list_replace_rcu(e, ne);
+				list_replace_rcu(&e->list, &ne->list);
 				call_rcu(&e->rcu, audit_free_rule);
 				return 0;
 			}
--- a/Documentation/RCU/rcuref.txt
+++ b/Documentation/RCU/rcuref.txt
@@ -20,7 +20,7 @@ release_referenced()			delete()
 {					{
    ...					    write_lock(&list_lock);
    atomic_dec(&el->rc, relfunc)	    ...
-    ...					    delete_element
+    ...					    remove_element
 }					    write_unlock(&list_lock);
 					    ...
 					    if (atomic_dec_and_test(&el->rc))
@@ -52,7 +52,7 @@ release_referenced()			delete()
 {					{
    ...					    spin_lock(&list_lock);
    if (atomic_dec_and_test(&el->rc))       ...
-        call_rcu(&el->head, el_free);       delete_element
+        call_rcu(&el->head, el_free);       remove_element
    ...                                     spin_unlock(&list_lock);
 } 					    ...
 					    if (atomic_dec_and_test(&el->rc))
@@ -64,3 +64,60 @@ Sometimes, a reference to the element needs to be obtained in the
 update (write) stream.  In such cases, atomic_inc_not_zero() might be
 overkill, since we hold the update-side spinlock.  One might instead
 use atomic_inc() in such cases.
 It is not always convenient to deal with "FAIL" in the
 search_and_reference() code path.  In such cases, the
 atomic_dec_and_test() may be moved from delete() to el_free()
 as follows:
 1.					2.
 add()					search_and_reference()
 {					{
    alloc_object			    rcu_read_lock();
    ...					    search_for_element
    atomic_set(&el->rc, 1);		    atomic_inc(&el->rc);
    spin_lock(&list_lock);		    ...
    add_element				    rcu_read_unlock();
    ...					}
    spin_unlock(&list_lock);		4.
 }					delete()
 3.					{
 release_referenced()			    spin_lock(&list_lock);
 {					    ...
    ...					    remove_element
    if (atomic_dec_and_test(&el->rc))       spin_unlock(&list_lock);
        kfree(el);			    ...
    ...                                     call_rcu(&el->head, el_free);
 } 					    ...
 5.					}
 void el_free(struct rcu_head *rhp)
 {
    release_referenced();
 }
 The key point is that the initial reference added by add() is not removed
 until after a grace period has elapsed following removal.  This means that
 search_and_reference() cannot find this element, which means that the value
 of el->rc cannot increase.  Thus, once it reaches zero, there are no
 readers that can or ever will be able to reference the element.  The
 element can therefore safely be freed.  This in turn guarantees that if
 any reader finds the element, that reader may safely acquire a reference
 without checking the value of the reference counter.
 In cases where delete() can sleep, synchronize_rcu() can be called from
 delete(), so that el_free() can be subsumed into delete as follows:
 4.
 delete()
 {
    spin_lock(&list_lock);
    ...
    remove_element
    spin_unlock(&list_lock);
    ...
    synchronize_rcu();
    if (atomic_dec_and_test(&el->rc))
    	kfree(el);
    ...
 }
--- a/Documentation/RCU/trace.txt
+++ b/Documentation/RCU/trace.txt
@@ -10,51 +10,63 @@ for rcutree and next for rcutiny.
 CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats
-These implementations of RCU provides several debugfs files under the
+These implementations of RCU provide several debugfs directories under the
 top-level directory "rcu":
-rcu/rcudata:
+rcu/rcu_bh
 rcu/rcu_preempt
 rcu/rcu_sched
 Each directory contains files for the corresponding flavor of RCU.
 Note that rcu/rcu_preempt is only present for CONFIG_TREE_PREEMPT_RCU.
 For CONFIG_TREE_RCU, the RCU flavor maps onto the RCU-sched flavor,
 so that activity for both appears in rcu/rcu_sched.
 In addition, the following file appears in the top-level directory:
 rcu/rcutorture.  This file displays rcutorture test progress.  The output
 of "cat rcu/rcutorture" looks as follows:
 rcutorture test sequence: 0 (test in progress)
 rcutorture update version number: 615
 The first line shows the number of rcutorture tests that have completed
 since boot.  If a test is currently running, the "(test in progress)"
 string will appear as shown above.  The second line shows the number of
 update cycles that the current test has started, or zero if there is
 no test in progress.
 Within each flavor directory (rcu/rcu_bh, rcu/rcu_sched, and possibly
 also rcu/rcu_preempt) the following files will be present:
 rcudata:
 	Displays fields in struct rcu_data.
-rcu/rcudata.csv:
+rcuexp:
-	Comma-separated values spreadsheet version of rcudata.
+	Displays statistics for expedited grace periods.
-rcu/rcugp:
+rcugp:
 	Displays grace-period counters.
-rcu/rcuhier:
+rcuhier:
 	Displays the struct rcu_node hierarchy.
-rcu/rcu_pending:
+rcu_pending:
 	Displays counts of the reasons rcu_pending() decided that RCU had
 	work to do.
-rcu/rcutorture:
+rcuboost:
 	Displays rcutorture test progress.
 rcu/rcuboost:
 	Displays RCU boosting statistics.  Only present if
 	CONFIG_RCU_BOOST=y.
-The output of "cat rcu/rcudata" looks as follows:
+The output of "cat rcu/rcu_preempt/rcudata" looks as follows:
-rcu_sched:
+  0!c=30455 g=30456 pq=1 qp=1 dt=126535/140000000000000/0 df=2002 of=4 ql=0/0 qs=N... b=10 ci=74572 nci=0 co=1131 ca=716
-  0 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=545/1/0 df=50 of=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
+  1!c=30719 g=30720 pq=1 qp=0 dt=132007/140000000000000/0 df=1874 of=10 ql=0/0 qs=N... b=10 ci=123209 nci=0 co=685 ca=982
-  1 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=967/1/0 df=58 of=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
+  2!c=30150 g=30151 pq=1 qp=1 dt=138537/140000000000000/0 df=1707 of=8 ql=0/0 qs=N... b=10 ci=80132 nci=0 co=1328 ca=1458
-  2 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1081/1/0 df=175 of=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
+  3 c=31249 g=31250 pq=1 qp=0 dt=107255/140000000000000/0 df=1749 of=6 ql=0/450 qs=NRW. b=10 ci=151700 nci=0 co=509 ca=622
-  3 c=20942 g=20943 pq=1 pgp=20942 qp=1 dt=1846/0/0 df=404 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
+  4!c=29502 g=29503 pq=1 qp=1 dt=83647/140000000000000/0 df=965 of=5 ql=0/0 qs=N... b=10 ci=65643 nci=0 co=1373 ca=1521
-  4 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=369/1/0 df=83 of=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
+  5 c=31201 g=31202 pq=1 qp=1 dt=70422/0/0 df=535 of=7 ql=0/0 qs=.... b=10 ci=58500 nci=0 co=764 ca=698
-  5 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=381/1/0 df=64 of=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
+  6!c=30253 g=30254 pq=1 qp=1 dt=95363/140000000000000/0 df=780 of=5 ql=0/0 qs=N... b=10 ci=100607 nci=0 co=1414 ca=1353
-  6 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1037/1/0 df=183 of=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
+  7 c=31178 g=31178 pq=1 qp=0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969
  7 c=20897 g=20897 pq=1 pgp=20896 qp=0 dt=1572/0/0 df=382 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
 rcu_bh:
  0 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=545/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
  1 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=967/1/0 df=3 of=0 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
  2 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1081/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
  3 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1846/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
  4 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=369/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
  5 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=381/1/0 df=4 of=0 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
  6 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1037/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
  7 c=1474 g=1474 pq=1 pgp=1473 qp=0 dt=1572/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
-The first section lists the rcu_data structures for rcu_sched, the second
+This file has one line per CPU, or eight for this 8-CPU system.
-for rcu_bh.  Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
+The fields are as follows:
 additional section for rcu_preempt.  Each section has one line per CPU,
 or eight for this 8-CPU system.  The fields are as follows:
 o	The number at the beginning of each line is the CPU number.
 	CPUs numbers followed by an exclamation mark are offline,
@@ -64,11 +76,13 @@ o	The number at the beginning of each line is the CPU number.
 	substantially larger than the number of actual CPUs.
 o	"c" is the count of grace periods that this CPU believes have
-	completed.  Offlined CPUs and CPUs in dynticks idle mode may
+	completed.  Offlined CPUs and CPUs in dynticks idle mode may lag
-	lag quite a ways behind, for example, CPU 6 under "rcu_sched"
+	quite a ways behind, for example, CPU 4 under "rcu_sched" above,
-	above, which has been offline through not quite 40,000 RCU grace
+	which has been offline through 16 RCU grace periods.  It is not
-	periods.  It is not unusual to see CPUs lagging by thousands of
+	unusual to see offline CPUs lagging by thousands of grace periods.
-	grace periods.
+	Note that although the grace-period number is an unsigned long,
 	it is printed out as a signed long to allow more human-friendly
 	representation near boot time.
 o	"g" is the count of grace periods that this CPU believes have
 	started.  Again, offlined CPUs and CPUs in dynticks idle mode
@@ -84,30 +98,25 @@ o	"pq" indicates that this CPU has passed through a quiescent state
 	CPU has not yet reported that fact, (2) some other CPU has not
 	yet reported for this grace period, or (3) both.
 o	"pgp" indicates which grace period the last-observed quiescent
 	state for this CPU corresponds to.  This is important for handling
 	the race between CPU 0 reporting an extended dynticks-idle
 	quiescent state for CPU 1 and CPU 1 suddenly waking up and
 	reporting its own quiescent state.  If CPU 1 was the last CPU
 	for the current grace period, then the CPU that loses this race
 	will attempt to incorrectly mark CPU 1 as having checked in for
 	the next grace period!
 o	"qp" indicates that RCU still expects a quiescent state from
 	this CPU.  Offlined CPUs and CPUs in dyntick idle mode might
 	well have qp=1, which is OK: RCU is still ignoring them.
 o	"dt" is the current value of the dyntick counter that is incremented
-	when entering or leaving dynticks idle state, either by the
+	when entering or leaving idle, either due to a context switch or
-	scheduler or by irq.  This number is even if the CPU is in
+	due to an interrupt.  This number is even if the CPU is in idle
-	dyntick idle mode and odd otherwise.  The number after the first
+	from RCU's viewpoint and odd otherwise.  The number after the
-	"/" is the interrupt nesting depth when in dyntick-idle state,
+	first "/" is the interrupt nesting depth when in idle state,
-	or one greater than the interrupt-nesting depth otherwise.
+	or a large number added to the interrupt-nesting depth when
-	The number after the second "/" is the NMI nesting depth.
+	running a non-idle task.  Some architectures do not accurately
 	count interrupt nesting when running in non-idle kernel context,
 	which can result in interesting anomalies such as negative
 	interrupt-nesting levels.  The number after the second "/"
 	is the NMI nesting depth.
 o	"df" is the number of times that some other CPU has forced a
 	quiescent state on behalf of this CPU due to this CPU being in
-	dynticks-idle state.
+	idle state.
 o	"of" is the number of times that some other CPU has forced a
 	quiescent state on behalf of this CPU due to this CPU being
@@ -120,9 +129,13 @@ o	"of" is the number of times that some other CPU has forced a
 	error, so it makes sense to err conservatively.
 o	"ql" is the number of RCU callbacks currently residing on
-	this CPU.  This is the total number of callbacks, regardless
+	this CPU.  The first number is the number of "lazy" callbacks
-	of what state they are in (new, waiting for grace period to
+	that are known to RCU to only be freeing memory, and the number
-	start, waiting for grace period to end, ready to invoke).
+	after the "/" is the total number of callbacks, lazy or not.
 	These counters count callbacks regardless of what phase of
 	grace-period processing that they are in (new, waiting for
 	grace period to start, waiting for grace period to end, ready
 	to invoke).
 o	"qs" gives an indication of the state of the callback queue
 	with four characters:
@@ -150,6 +163,43 @@ o	"qs" gives an indication of the state of the callback queue
 	If there are no callbacks in a given one of the above states,
 	the corresponding character is replaced by ".".
 o	"b" is the batch limit for this CPU.  If more than this number
 	of RCU callbacks is ready to invoke, then the remainder will
 	be deferred.
 o	"ci" is the number of RCU callbacks that have been invoked for
 	this CPU.  Note that ci+nci+ql is the number of callbacks that have
 	been registered in absence of CPU-hotplug activity.
 o	"nci" is the number of RCU callbacks that have been offloaded from
 	this CPU.  This will always be zero unless the kernel was built
 	with CONFIG_RCU_NOCB_CPU=y and the "rcu_nocbs=" kernel boot
 	parameter was specified.
 o	"co" is the number of RCU callbacks that have been orphaned due to
 	this CPU going offline.  These orphaned callbacks have been moved
 	to an arbitrarily chosen online CPU.
 o	"ca" is the number of RCU callbacks that have been adopted by this
 	CPU due to other CPUs going offline.  Note that ci+co-ca+ql is
 	the number of RCU callbacks registered on this CPU.
 Kernels compiled with CONFIG_RCU_BOOST=y display the following from
 /debug/rcu/rcu_preempt/rcudata:
  0!c=12865 g=12866 pq=1 qp=1 dt=83113/140000000000000/0 df=288 of=11 ql=0/0 qs=N... kt=0/O ktl=944 b=10 ci=60709 nci=0 co=748 ca=871
  1 c=14407 g=14408 pq=1 qp=0 dt=100679/140000000000000/0 df=378 of=7 ql=0/119 qs=NRW. kt=0/W ktl=9b6 b=10 ci=109740 nci=0 co=589 ca=485
  2 c=14407 g=14408 pq=1 qp=0 dt=105486/0/0 df=90 of=9 ql=0/89 qs=NRW. kt=0/W ktl=c0c b=10 ci=83113 nci=0 co=533 ca=490
  3 c=14407 g=14408 pq=1 qp=0 dt=107138/0/0 df=142 of=8 ql=0/188 qs=NRW. kt=0/W ktl=b96 b=10 ci=121114 nci=0 co=426 ca=290
  4 c=14405 g=14406 pq=1 qp=1 dt=50238/0/0 df=706 of=7 ql=0/0 qs=.... kt=0/W ktl=812 b=10 ci=34929 nci=0 co=643 ca=114
  5!c=14168 g=14169 pq=1 qp=0 dt=45465/140000000000000/0 df=161 of=11 ql=0/0 qs=N... kt=0/O ktl=b4d b=10 ci=47712 nci=0 co=677 ca=722
  6 c=14404 g=14405 pq=1 qp=0 dt=59454/0/0 df=94 of=6 ql=0/0 qs=.... kt=0/W ktl=e57 b=10 ci=55597 nci=0 co=701 ca=811
  7 c=14407 g=14408 pq=1 qp=1 dt=68850/0/0 df=31 of=8 ql=0/0 qs=.... kt=0/W ktl=14bd b=10 ci=77475 nci=0 co=508 ca=1042
 This is similar to the output discussed above, but contains the following
 additional fields:
 o	"kt" is the per-CPU kernel-thread state.  The digit preceding
 	the first slash is zero if there is no work pending and 1
 	otherwise.  The character between the first pair of slashes is
@@ -184,35 +234,51 @@ o	"ktl" is the low-order 16 bits (in hexadecimal) of the count of
 	This field is displayed only for CONFIG_RCU_BOOST kernels.
 o	"b" is the batch limit for this CPU.  If more than this number
 	of RCU callbacks is ready to invoke, then the remainder will
 	be deferred.
-o	"ci" is the number of RCU callbacks that have been invoked for
+The output of "cat rcu/rcu_preempt/rcuexp" looks as follows:
 	this CPU.  Note that ci+ql is the number of callbacks that have
 	been registered in absence of CPU-hotplug activity.
-o	"co" is the number of RCU callbacks that have been orphaned due to
+s=21872 d=21872 w=0 tf=0 wd1=0 wd2=0 n=0 sc=21872 dt=21872 dl=0 dx=21872
 	this CPU going offline.  These orphaned callbacks have been moved
 	to an arbitrarily chosen online CPU.
-o	"ca" is the number of RCU callbacks that have been adopted due to
+These fields are as follows:
 	other CPUs going offline.  Note that ci+co-ca+ql is the number of
 	RCU callbacks registered on this CPU.
-There is also an rcu/rcudata.csv file with the same information in
+o	"s" is the starting sequence number.
-comma-separated-variable spreadsheet format.
+
 o	"d" is the ending sequence number.  When the starting and ending
 	numbers differ, there is an expedited grace period in progress.
 o	"w" is the number of times that the sequence numbers have been
 	in danger of wrapping.
 o	"tf" is the number of times that contention has resulted in a
 	failure to begin an expedited grace period.
 o	"wd1" and "wd2" are the number of times that an attempt to
 	start an expedited grace period found that someone else had
 	completed an expedited grace period that satisfies the
 	attempted request.  "Our work is done."
 o	"n" is number of times that contention was so great that
 	the request was demoted from an expedited grace period to
 	a normal grace period.
 o	"sc" is the number of times that the attempt to start a
 	new expedited grace period succeeded.
 o	"dt" is the number of times that we attempted to update
 	the "d" counter.
 o	"dl" is the number of times that we failed to update the "d"
 	counter.
 o	"dx" is the number of times that we succeeded in updating
 	the "d" counter.
-The output of "cat rcu/rcugp" looks as follows:
+The output of "cat rcu/rcu_preempt/rcugp" looks as follows:
-rcu_sched: completed=33062  gpnum=33063
+completed=31249  gpnum=31250  age=1  max=18
 rcu_bh: completed=464  gpnum=464
-Again, this output is for both "rcu_sched" and "rcu_bh".  Note that
+These fields are taken from the rcu_state structure, and are as follows:
 kernels built with CONFIG_TREE_PREEMPT_RCU will have an additional
 "rcu_preempt" line.  The fields are taken from the rcu_state structure,
 and are as follows:
 o	"completed" is the number of grace periods that have completed.
 	It is comparable to the "c" field from rcu/rcudata in that a
@@ -220,44 +286,42 @@ o	"completed" is the number of grace periods that have completed.
 	that the corresponding RCU grace period has completed.
 o	"gpnum" is the number of grace periods that have started.  It is
-	comparable to the "g" field from rcu/rcudata in that a CPU
+	similarly comparable to the "g" field from rcu/rcudata in that
-	whose "g" field matches the value of "gpnum" is aware that the
+	a CPU whose "g" field matches the value of "gpnum" is aware that
-	corresponding RCU grace period has started.
+	the corresponding RCU grace period has started.
-	If these two fields are equal (as they are for "rcu_bh" above),
+	If these two fields are equal, then there is no grace period
-	then there is no grace period in progress, in other words, RCU
+	in progress, in other words, RCU is idle.  On the other hand,
-	is idle.  On the other hand, if the two fields differ (as they
+	if the two fields differ (as they are above), then an RCU grace
-	do for "rcu_sched" above), then an RCU grace period is in progress.
+	period is in progress.
 o	"age" is the number of jiffies that the current grace period
 	has extended for, or zero if there is no grace period currently
 	in effect.
-The output of "cat rcu/rcuhier" looks as follows, with very long lines:
+o	"max" is the age in jiffies of the longest-duration grace period
 	thus far.
-c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6
+The output of "cat rcu/rcu_preempt/rcuhier" looks as follows:
 1/1 ..>. 0:127 ^0
 3/3 ..>. 0:35 ^0    0/0 ..>. 36:71 ^1    0/0 ..>. 72:107 ^2    0/0 ..>. 108:127 ^3
 3/3f ..>. 0:5 ^0    2/3 ..>. 6:11 ^1    0/0 ..>. 12:17 ^2    0/0 ..>. 18:23 ^3    0/0 ..>. 24:29 ^4    0/0 ..>. 30:35 ^5    0/0 ..>. 36:41 ^0    0/0 ..>. 42:47 ^1    0/0 ..>. 48:53 ^2    0/0 ..>. 54:59 ^3    0/0 ..>. 60:65 ^4    0/0 ..>. 66:71 ^5    0/0 ..>. 72:77 ^0    0/0 ..>. 78:83 ^1    0/0 ..>. 84:89 ^2    0/0 ..>. 90:95 ^3    0/0 ..>. 96:101 ^4    0/0 ..>. 102:107 ^5    0/0 ..>. 108:113 ^0    0/0 ..>. 114:119 ^1    0/0 ..>. 120:125 ^2    0/0 ..>. 126:127 ^3
 rcu_bh:
 c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0
 0/1 ..>. 0:127 ^0
 0/3 ..>. 0:35 ^0    0/0 ..>. 36:71 ^1    0/0 ..>. 72:107 ^2    0/0 ..>. 108:127 ^3
 0/3f ..>. 0:5 ^0    0/3 ..>. 6:11 ^1    0/0 ..>. 12:17 ^2    0/0 ..>. 18:23 ^3    0/0 ..>. 24:29 ^4    0/0 ..>. 30:35 ^5    0/0 ..>. 36:41 ^0    0/0 ..>. 42:47 ^1    0/0 ..>. 48:53 ^2    0/0 ..>. 54:59 ^3    0/0 ..>. 60:65 ^4    0/0 ..>. 66:71 ^5    0/0 ..>. 72:77 ^0    0/0 ..>. 78:83 ^1    0/0 ..>. 84:89 ^2    0/0 ..>. 90:95 ^3    0/0 ..>. 96:101 ^4    0/0 ..>. 102:107 ^5    0/0 ..>. 108:113 ^0    0/0 ..>. 114:119 ^1    0/0 ..>. 120:125 ^2    0/0 ..>. 126:127 ^3
-This is once again split into "rcu_sched" and "rcu_bh" portions,
+c=14407 g=14408 s=0 jfq=2 j=c863 nfqs=12040/nfqsng=0(12040) fqlh=1051 oqlen=0/0
-and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional
+3/3 ..>. 0:7 ^0
-"rcu_preempt" section.  The fields are as follows:
+e/e ..>. 0:3 ^0    d/d ..>. 4:7 ^1
-o	"c" is exactly the same as "completed" under rcu/rcugp.
+The fields are as follows:
-o	"g" is exactly the same as "gpnum" under rcu/rcugp.
+o	"c" is exactly the same as "completed" under rcu/rcu_preempt/rcugp.
-o	"s" is the "signaled" state that drives force_quiescent_state()'s
+o	"g" is exactly the same as "gpnum" under rcu/rcu_preempt/rcugp.
 o	"s" is the current state of the force_quiescent_state()
 	state machine.
 o	"jfq" is the number of jiffies remaining for this grace period
 	before force_quiescent_state() is invoked to help push things
-	along.  Note that CPUs in dyntick-idle mode throughout the grace
+	along.	Note that CPUs in idle mode throughout the grace period
-	period will not report on their own, but rather must be check by
+	will not report on their own, but rather must be check by some
-	some other CPU via force_quiescent_state().
+	other CPU via force_quiescent_state().
 o	"j" is the low-order four hex digits of the jiffies counter.
 	Yes, Paul did run into a number of problems that turned out to
@@ -268,7 +332,8 @@ o	"nfqs" is the number of calls to force_quiescent_state() since
 o	"nfqsng" is the number of useless calls to force_quiescent_state(),
 	where there wasn't actually a grace period active.  This can
-	happen due to races.  The number in parentheses is the difference
+	no longer happen due to grace-period processing being pushed
 	into a kthread.  The number in parentheses is the difference
 	between "nfqs" and "nfqsng", or the number of times that
 	force_quiescent_state() actually did some real work.
@@ -276,28 +341,27 @@ o	"fqlh" is the number of calls to force_quiescent_state() that
 	exited immediately (without even being counted in nfqs above)
 	due to contention on ->fqslock.
-o	Each element of the form "1/1 0:127 ^0" represents one struct
+o	Each element of the form "3/3 ..>. 0:7 ^0" represents one rcu_node
-	rcu_node.  Each line represents one level of the hierarchy, from
+	structure.  Each line represents one level of the hierarchy,
-	root to leaves.  It is best to think of the rcu_data structures
+	from root to leaves.  It is best to think of the rcu_data
-	as forming yet another level after the leaves.  Note that there
+	structures as forming yet another level after the leaves.
-	might be either one, two, or three levels of rcu_node structures,
+	Note that there might be either one, two, three, or even four
-	depending on the relationship between CONFIG_RCU_FANOUT and
+	levels of rcu_node structures, depending on the relationship
-	CONFIG_NR_CPUS.
+	between CONFIG_RCU_FANOUT, CONFIG_RCU_FANOUT_LEAF (possibly
 	adjusted using the rcu_fanout_leaf kernel boot parameter), and
 	CONFIG_NR_CPUS (possibly adjusted using the nr_cpu_ids count of
 	possible CPUs for the booting hardware).
 	o	The numbers separated by the "/" are the qsmask followed
 		by the qsmaskinit.  The qsmask will have one bit
-		set for each entity in the next lower level that
+		set for each entity in the next lower level that has
-		has not yet checked in for the current grace period.
+		not yet checked in for the current grace period ("e"
 		indicating CPUs 5, 6, and 7 in the example above).
 		The qsmaskinit will have one bit for each entity that is
 		currently expected to check in during each grace period.
 		The value of qsmaskinit is assigned to that of qsmask
 		at the beginning of each grace period.
 		For example, for "rcu_sched", the qsmask of the first
 		entry of the lowest level is 0x14, meaning that we
 		are still waiting for CPUs 2 and 4 to check in for the
 		current grace period.
 	o	The characters separated by the ">" indicate the state
 		of the blocked-tasks lists.  A "G" preceding the ">"
 		indicates that at least one task blocked in an RCU
@@ -312,48 +376,39 @@ o	Each element of the form "1/1 0:127 ^0" represents one struct
 		A "." character appears if the corresponding condition
 		does not hold, so that "..>." indicates that no tasks
 		are blocked.  In contrast, "GE>T" indicates maximal
-		inconvenience from blocked tasks.
+		inconvenience from blocked tasks.  CONFIG_TREE_RCU
 		builds of the kernel will always show "..>.".
 	o	The numbers separated by the ":" are the range of CPUs
 		served by this struct rcu_node.  This can be helpful
 		in working out how the hierarchy is wired together.
-		For example, the first entry at the lowest level shows
+		For example, the example rcu_node structure shown above
-		"0:5", indicating that it covers CPUs 0 through 5.
+		has "0:7", indicating that it covers CPUs 0 through 7.
 	o	The number after the "^" indicates the bit in the
-		next higher level rcu_node structure that this
+		next higher level rcu_node structure that this rcu_node
-		rcu_node structure corresponds to.
+		structure corresponds to.  For example, the "d/d ..>. 4:7
-
+		^1" has a "1" in this position, indicating that it
-		For example, the first entry at the lowest level shows
+		corresponds to the "1" bit in the "3" shown in the
-		"^0", indicating that it corresponds to bit zero in
+		"3/3 ..>. 0:7 ^0" entry on the next level up.
 		the first entry at the middle level.
-The output of "cat rcu/rcu_pending" looks as follows:
+The output of "cat rcu/rcu_sched/rcu_pending" looks as follows:
-rcu_sched:
+  0!np=26111 qsp=29 rpq=5386 cbr=1 cng=570 gpc=3674 gps=577 nn=15903
-  0 np=255892 qsp=53936 rpq=85 cbr=0 cng=14417 gpc=10033 gps=24320 nn=146741
+  1!np=28913 qsp=35 rpq=6097 cbr=1 cng=448 gpc=3700 gps=554 nn=18113
-  1 np=261224 qsp=54638 rpq=33 cbr=0 cng=25723 gpc=16310 gps=2849 nn=155792
+  2!np=32740 qsp=37 rpq=6202 cbr=0 cng=476 gpc=4627 gps=546 nn=20889
-  2 np=237496 qsp=49664 rpq=23 cbr=0 cng=2762 gpc=45478 gps=1762 nn=136629
+  3 np=23679 qsp=22 rpq=5044 cbr=1 cng=415 gpc=3403 gps=347 nn=14469
-  3 np=236249 qsp=48766 rpq=98 cbr=0 cng=286 gpc=48049 gps=1218 nn=137723
+  4!np=30714 qsp=4 rpq=5574 cbr=0 cng=528 gpc=3931 gps=639 nn=20042
-  4 np=221310 qsp=46850 rpq=7 cbr=0 cng=26 gpc=43161 gps=4634 nn=123110
+  5 np=28910 qsp=2 rpq=5246 cbr=0 cng=428 gpc=4105 gps=709 nn=18422
-  5 np=237332 qsp=48449 rpq=9 cbr=0 cng=54 gpc=47920 gps=3252 nn=137456
+  6!np=38648 qsp=5 rpq=7076 cbr=0 cng=840 gpc=4072 gps=961 nn=25699
-  6 np=219995 qsp=46718 rpq=12 cbr=0 cng=50 gpc=42098 gps=6093 nn=120834
+  7 np=37275 qsp=2 rpq=6873 cbr=0 cng=868 gpc=3416 gps=971 nn=25147
  7 np=249893 qsp=49390 rpq=42 cbr=0 cng=72 gpc=38400 gps=17102 nn=144888
 rcu_bh:
  0 np=146741 qsp=1419 rpq=6 cbr=0 cng=6 gpc=0 gps=0 nn=145314
  1 np=155792 qsp=12597 rpq=3 cbr=0 cng=0 gpc=4 gps=8 nn=143180
  2 np=136629 qsp=18680 rpq=1 cbr=0 cng=0 gpc=7 gps=6 nn=117936
  3 np=137723 qsp=2843 rpq=0 cbr=0 cng=0 gpc=10 gps=7 nn=134863
  4 np=123110 qsp=12433 rpq=0 cbr=0 cng=0 gpc=4 gps=2 nn=110671
  5 np=137456 qsp=4210 rpq=1 cbr=0 cng=0 gpc=6 gps=5 nn=133235
  6 np=120834 qsp=9902 rpq=2 cbr=0 cng=0 gpc=6 gps=3 nn=110921
  7 np=144888 qsp=26336 rpq=0 cbr=0 cng=0 gpc=8 gps=2 nn=118542
-As always, this is once again split into "rcu_sched" and "rcu_bh"
+The fields are as follows:
-portions, with CONFIG_TREE_PREEMPT_RCU kernels having an additional
+
-"rcu_preempt" section.  The fields are as follows:
+o	The leading number is the CPU number, with "!" indicating
 	an offline CPU.
 o	"np" is the number of times that __rcu_pending() has been invoked
 	for the corresponding flavor of RCU.
@@ -377,38 +432,23 @@ o	"gpc" is the number of times that an old grace period had
 o	"gps" is the number of times that a new grace period had started,
 	but this CPU was not yet aware of it.
-o	"nn" is the number of times that this CPU needed nothing.  Alert
+o	"nn" is the number of times that this CPU needed nothing.
 	readers will note that the rcu "nn" number for a given CPU very
 	closely matches the rcu_bh "np" number for that same CPU.  This
 	is due to short-circuit evaluation in rcu_pending().
 The output of "cat rcu/rcutorture" looks as follows:
 rcutorture test sequence: 0 (test in progress)
 rcutorture update version number: 615
 The first line shows the number of rcutorture tests that have completed
 since boot.  If a test is currently running, the "(test in progress)"
 string will appear as shown above.  The second line shows the number of
 update cycles that the current test has started, or zero if there is
 no test in progress.
 The output of "cat rcu/rcuboost" looks as follows:
-0:5 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
+0:3 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=c864 bt=c894
-     balk: nt=0 egt=989 bt=0 nb=0 ny=0 nos=16
+    balk: nt=0 egt=4695 bt=0 nb=0 ny=56 nos=0
-6:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
+4:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=c864 bt=c894
-     balk: nt=0 egt=225 bt=0 nb=0 ny=0 nos=6
+    balk: nt=0 egt=6541 bt=0 nb=0 ny=126 nos=0
 This information is output only for rcu_preempt.  Each two-line entry
 corresponds to a leaf rcu_node strcuture.  The fields are as follows:
 o	"n:m" is the CPU-number range for the corresponding two-line
 	entry.  In the sample output above, the first entry covers
-	CPUs zero through five and the second entry covers CPUs 6
+	CPUs zero through three and the second entry covers CPUs four
-	and 7.
+	through seven.
 o	"tasks=TNEB" gives the state of the various segments of the
 	rnp->blocked_tasks list:
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -499,6 +499,8 @@ The foo_reclaim() function might appear as follows:
 	{
 		struct foo *fp = container_of(rp, struct foo, rcu);
 		foo_cleanup(fp->a);
 		kfree(fp);
 	}
@@ -521,6 +523,12 @@ o	Use call_rcu() -after- removing a data element from an
 	read-side critical sections that might be referencing that
 	data item.
 If the callback for call_rcu() is not doing anything more than calling
 kfree() on the structure, you can use kfree_rcu() instead of call_rcu()
 to avoid having to write your own callback:
 	kfree_rcu(old_fp, rcu);
 Again, see checklist.txt for additional rules governing the use of RCU.
@@ -773,8 +781,8 @@ a single atomic update, converting to RCU will require special care.
 Also, the presence of synchronize_rcu() means that the RCU version of
 delete() can now block.  If this is a problem, there is a callback-based
-mechanism that never blocks, namely call_rcu(), that can be used in
+mechanism that never blocks, namely call_rcu() or kfree_rcu(), that can
-place of synchronize_rcu().
+be used in place of synchronize_rcu().
 7.  FULL LIST OF RCU APIs
@@ -789,9 +797,7 @@ RCU list traversal:
 	list_for_each_entry_rcu
 	hlist_for_each_entry_rcu
 	hlist_nulls_for_each_entry_rcu
-
+	list_for_each_entry_continue_rcu
 	list_for_each_continue_rcu	(to be deprecated in favor of new
 					 list_for_each_entry_continue_rcu)
 RCU pointer/list update:
@@ -813,6 +819,7 @@ RCU:	Critical sections	Grace period		Barrier
 	rcu_read_unlock		synchronize_rcu
 	rcu_dereference		synchronize_rcu_expedited
 				call_rcu
 				kfree_rcu
 bh:	Critical sections	Grace period		Barrier
--- a/Show More
+++ b/Show More