Merge pull request #1011 from notro/sweeping

BCM270x: Clean out unused code

.get_maintainer.ignore

@@ -1 +0,0 @@
-Christoph Hellwig <hch@lst.de>

.gitignore

@@ -24,7 +24,6 @@
 *.order
 *.elf
 *.bin
-*.tar
 *.gz
 *.bz2
 *.lzma
@@ -36,7 +35,6 @@
 modules.builtin
 Module.symvers
 *.dwo
-*.su
 
 #
 # Top-level generic files
@@ -45,7 +43,6 @@ Module.symvers
 /TAGS
 /linux
 /vmlinux
-/vmlinux.32
 /vmlinux-gdb.py
 /vmlinuz
 /System.map
@@ -91,9 +88,6 @@ GRTAGS
 GSYMS
 GTAGS
 
-# id-utils files
-ID
-
 *.orig
 *~
 \#*#
@@ -102,7 +96,6 @@ ID
 # Leavings from module signing
 #
 extra_certificates
-signing_key.pem
 signing_key.priv
 signing_key.x509
 x509.genkey

.mailmap

@@ -17,7 +17,6 @@ Aleksey Gorelov <aleksey_gorelov@phoenix.com>
 Al Viro <viro@ftp.linux.org.uk>
 Al Viro <viro@zenIV.linux.org.uk>
 Andreas Herrmann <aherrman@de.ibm.com>
-Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
 Andrew Morton <akpm@linux-foundation.org>
 Andrew Vasquez <andrew.vasquez@qlogic.com>
 Andy Adamson <andros@citi.umich.edu>
@@ -59,7 +58,6 @@ James Bottomley <jejb@mulgrave.(none)>
 James Bottomley <jejb@titanic.il.steeleye.com>
 James E Wilson <wilson@specifix.com>
 James Ketrenos <jketreno@io.(none)>
-<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
 Jean Tourrilhes <jt@hpl.hp.com>
 Jeff Garzik <jgarzik@pretzel.yyz.us>
 Jens Axboe <axboe@suse.de>
@@ -86,7 +84,6 @@ Mayuresh Janorkar <mayur@ti.com>
 Michael Buesch <m@bues.ch>
 Michel Dänzer <michel@tungstengraphics.com>
 Mitesh shah <mshah@teja.com>
-Mohit Kumar <mohit.kumar@st.com> <mohit.kumar.dhaka@gmail.com>
 Morten Welinder <terra@gnome.org>
 Morten Welinder <welinder@anemone.rentec.com>
 Morten Welinder <welinder@darter.rentec.com>
@@ -98,14 +95,11 @@ Patrick Mochel <mochel@digitalimplant.org>
 Peter A Jonsson <pj@ludd.ltu.se>
 Peter Oruba <peter@oruba.de>
 Peter Oruba <peter.oruba@amd.com>
-Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
 Praveen BP <praveenbp@ti.com>
 Rajesh Shah <rajesh.shah@intel.com>
 Ralf Baechle <ralf@linux-mips.org>
 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
-Randy Dunlap <rdunlap@infradead.org> <rdunlap@xenotime.net>
 Rémi Denis-Courmont <rdenis@simphalempin.com>
-Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
 Rudolf Marek <R.Marek@sh.cvut.cz>
 Rui Saraiva <rmps@joel.ist.utl.pt>
 Sachin P Sant <ssant@in.ibm.com>
@@ -118,7 +112,6 @@ Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
 Simon Kelley <simon@thekelleys.org.uk>
 Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
 Stephen Hemminger <shemminger@osdl.org>
-Sudeep Holla <sudeep.holla@arm.com> Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
 Sumit Semwal <sumit.semwal@ti.com>
 Tejun Heo <htejun@gmail.com>
 Thomas Graf <tgraf@suug.ch>
@@ -128,9 +121,7 @@ Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
 Uwe Kleine-König <ukl@pengutronix.de>
 Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
 Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
-Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com>
-Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
-Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com>
+Viresh Kumar <viresh.linux@gmail.com> <viresh.kumar@st.com>
 Takashi YOSHII <takashi.yoshii.zj@renesas.com>
 Yusuke Goda <goda.yusuke@renesas.com>
 Gustavo Padovan <gustavo@las.ic.unicamp.br>

CREDITS

@@ -20,10 +20,6 @@ D: One of assisting postmasters for vger.kernel.org's lists
 S: (ask for current address)
 S: Finland
 
-N: Thomas Abraham
-E: thomas.ab@samsung.com
-D: Samsung pin controller driver
-
 N: Dragos Acostachioaie
 E: dragos@iname.com
 W: http://www.arbornet.org/~dragos
@@ -191,10 +187,6 @@ N: Krishna Balasubramanian
 E: balasub@cis.ohio-state.edu
 D: Wrote SYS V IPC (part of standard kernel since 0.99.10)
 
-N: Chris Ball
-E: chris@printf.net
-D: Former maintainer of the MMC/SD/SDIO subsystem.
-
 N: Dario Ballabio
 E: ballabio_dario@emc.com
 E: dario.ballabio@tiscalinet.it
@@ -512,10 +504,6 @@ E: paul@paulbristow.net
 W: http://paulbristow.net/linux/idefloppy.html
 D: Maintainer of IDE/ATAPI floppy driver
 
-N: Stefano Brivio
-E: stefano.brivio@polimi.it
-D: Broadcom B43 driver
-
 N: Dominik Brodowski
 E: linux@brodo.de
 W: http://www.brodo.de/
@@ -2053,10 +2041,6 @@ D: pirq addr, CS5535 alsa audio driver
 S: Gurgaon, India
 S: Kuala Lumpur, Malaysia
 
-N: Mohit Kumar
-D: ST Microelectronics SPEAr13xx PCI host bridge driver
-D: Synopsys Designware PCI host bridge driver
-
 N: Gabor Kuti
 M: seasons@falcon.sch.bme.hu
 M: seasons@makosteszta.sote.hu
@@ -2744,10 +2728,6 @@ S: C/ Mieses 20, 9-B
 S: Valladolid 47009
 S: Spain
 
-N: Jens Osterkamp
-E: jens@de.ibm.com
-D: Maintainer of Spidernet network driver for Cell
-
 N: Gadi Oxman
 E: gadio@netvision.net.il
 D: Original author and maintainer of IDE/ATAPI floppy/tape drivers
@@ -2992,10 +2972,6 @@ S: 2200 Mission College Blvd
 S: Santa Clara, CA 95052
 S: USA
 
-N: Anil Ravindranath
-E: anil_ravindranath@pmc-sierra.com
-D: PMC-Sierra MaxRAID driver
-
 N: Eric S. Raymond
 E: esr@thyrsus.com
 W: http://www.tuxedo.org/~esr/
@@ -3028,19 +3004,6 @@ W: http://www.qsl.net/dl1bke/
 D: Generic Z8530 driver, AX.25 DAMA slave implementation
 D: Several AX.25 hacks
 
-N: Ricardo Ribalda Delgado
-E: ricardo.ribalda@gmail.com
-W: http://ribalda.com
-D: PLX USB338x driver
-D: PCA9634 driver
-D: Option GTM671WFS
-D: Fintek F81216A
-D: Various kernel hacks
-S: Qtechnology A/S
-S: Valby Langgade 142
-S: 2500 Valby
-S: Denmark
-
 N: Francois-Rene Rideau
 E: fare@tunes.org
 W: http://www.tunes.org/~fare
@@ -3227,15 +3190,15 @@ S: 69 rue Dunois
 S: 75013 Paris
 S: France
 
-N: Aleksa Sarai
-E: cyphar@cyphar.com
-W: https://www.cyphar.com/
-D: `pids` cgroup subsystem
-
 N: Dipankar Sarma
 E: dipankar@in.ibm.com
 D: RCU
 
+N: Yoshinori Sato
+E: ysato@users.sourceforge.jp
+D: uClinux for Renesas H8/300 (H8300)
+D: http://uclinux-h8.sourceforge.jp/
+
 N: Hannu Savolainen
 E: hannu@opensound.com
 D: Maintainer of the sound drivers until 2.1.x days.
@@ -3721,13 +3684,6 @@ N: Dirk Verworner
 D: Co-author of German book ``Linux-Kernel-Programmierung''
 D: Co-founder of Berlin Linux User Group
 
-N: Andrew Victor
-E: linux@maxim.org.za
-W: http://maxim.org.za/at91_26.html
-D: First maintainer of Atmel ARM-based SoC, aka AT91
-D: Introduced support for at91rm9200, the first chip of AT91 family
-S: South Africa
-
 N: Riku Voipio
 E: riku.voipio@iki.fi
 D: Author of PCA9532 LED and Fintek f75375s hwmon driver

Documentation/ABI/obsolete/sysfs-block-zram

@@ -1,119 +0,0 @@
-What:		/sys/block/zram<id>/num_reads
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The num_reads file is read-only and specifies the number of
-		reads (failed or successful) done on this device.
-		Now accessible via zram<id>/stat node.
-
-What:		/sys/block/zram<id>/num_writes
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The num_writes file is read-only and specifies the number of
-		writes (failed or successful) done on this device.
-		Now accessible via zram<id>/stat node.
-
-What:		/sys/block/zram<id>/invalid_io
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The invalid_io file is read-only and specifies the number of
-		non-page-size-aligned I/O requests issued to this device.
-		Now accessible via zram<id>/io_stat node.
-
-What:		/sys/block/zram<id>/failed_reads
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The failed_reads file is read-only and specifies the number of
-		failed reads happened on this device.
-		Now accessible via zram<id>/io_stat node.
-
-What:		/sys/block/zram<id>/failed_writes
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The failed_writes file is read-only and specifies the number of
-		failed writes happened on this device.
-		Now accessible via zram<id>/io_stat node.
-
-What:		/sys/block/zram<id>/notify_free
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The notify_free file is read-only. Depending on device usage
-		scenario it may account a) the number of pages freed because
-		of swap slot free notifications or b) the number of pages freed
-		because of REQ_DISCARD requests sent by bio. The former ones
-		are sent to a swap block device when a swap slot is freed, which
-		implies that this disk is being used as a swap disk. The latter
-		ones are sent by filesystem mounted with discard option,
-		whenever some data blocks are getting discarded.
-		Now accessible via zram<id>/io_stat node.
-
-What:		/sys/block/zram<id>/zero_pages
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The zero_pages file is read-only and specifies number of zero
-		filled pages written to this disk. No memory is allocated for
-		such pages.
-		Now accessible via zram<id>/mm_stat node.
-
-What:		/sys/block/zram<id>/orig_data_size
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The orig_data_size file is read-only and specifies uncompressed
-		size of data stored in this disk. This excludes zero-filled
-		pages (zero_pages) since no memory is allocated for them.
-		Unit: bytes
-		Now accessible via zram<id>/mm_stat node.
-
-What:		/sys/block/zram<id>/compr_data_size
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The compr_data_size file is read-only and specifies compressed
-		size of data stored in this disk. So, compression ratio can be
-		calculated using orig_data_size and this statistic.
-		Unit: bytes
-		Now accessible via zram<id>/mm_stat node.
-
-What:		/sys/block/zram<id>/mem_used_total
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The mem_used_total file is read-only and specifies the amount
-		of memory, including allocator fragmentation and metadata
-		overhead, allocated for this disk. So, allocator space
-		efficiency can be calculated using compr_data_size and this
-		statistic.
-		Unit: bytes
-		Now accessible via zram<id>/mm_stat node.
-
-What:		/sys/block/zram<id>/mem_used_max
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The mem_used_max file is read/write and specifies the amount
-		of maximum memory zram have consumed to store compressed data.
-		For resetting the value, you should write "0". Otherwise,
-		you could see -EINVAL.
-		Unit: bytes
-		Downgraded to write-only node: so it's possible to set new
-		value only; its current value is stored in zram<id>/mm_stat
-		node.
-
-What:		/sys/block/zram<id>/mem_limit
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The mem_limit file is read/write and specifies the maximum
-		amount of memory ZRAM can use to store the compressed data.
-		The limit could be changed in run time and "0" means disable
-		the limit.  No limit is the initial state.  Unit: bytes
-		Downgraded to write-only node: so it's possible to set new
-		value only; its current value is stored in zram<id>/mm_stat
-		node.

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus

@@ -1,14 +1,3 @@
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
-Date:		October 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 actual
-                profile. This value is persistent, so its equivalent to the
-                profile that's active when the mouse is powered on next time.
-		When written, this file sets the number of the startup profile
-		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>/startup_profile
 Date:		October 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
@@ -33,40 +22,6 @@ Description:	When read, this file returns the raw integer version number of the
 		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>/info
-Date:		November 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.
-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
-Date:		October 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The mouse can store a macro with max 500 key/button strokes
-		internally.
-		When written, this file lets one set the sequence for a specific
-		button for a specific profile. Button and profile numbers are
-		included in written data. The data has to be 2082 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>/koneplus/roccatkoneplus<minor>/profile_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 written, this file lets one write the respective profile
-		buttons back to the mouse. The data has to be 77 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile 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>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
@@ -79,22 +34,6 @@ Description:	The mouse can store 5 profiles which can be switched by the
 		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_settings
-Date:		October 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 written, this file lets one write the respective profile
-		settings back to the mouse. The data has to be 43 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile 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>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
@@ -106,40 +45,4 @@ Description:	The mouse can store 5 profiles which can be switched by the
 		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
-
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/sensor
-Date:		October 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	The mouse has a tracking- and a distance-control-unit. These
-		can be activated/deactivated and the lift-off distance can be
-		set. The data has to be 6 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>/koneplus/roccatkoneplus<minor>/talk
-Date:		May 2011
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	Used to active some easy* functions of the mouse from outside.
-		The data has to be 16 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>/koneplus/roccatkoneplus<minor>/tcu
-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. Also lets one read/write sensor
-		registers.
-		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
-Date:		October 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	When read the mouse returns a 30x30 pixel image of the
-		sampled underground. This works only in the course of a
-		calibration process initiated with tcu.
-		The returned data is 1028 bytes in size.
-		This file is readonly.
-Users:		http://roccat.sourceforge.net
+Users:		http://roccat.sourceforge.net

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus

@@ -8,17 +8,6 @@ Description:	The integer value of this attribute ranges from 1-4.
 		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_profile
-Date:		January 2011
-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 active
-		profile.
-		When written, the mouse activates this profile immediately.
-		The profile that's active when powered down is the same that's
-		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
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
@@ -51,29 +40,6 @@ Description:	When read, this file returns the raw integer version number of the
 		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>/info
-Date:		November 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 6 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>/kovaplus/roccatkovaplus<minor>/profile_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 written, this file lets one write the respective profile
-		buttons back to the mouse. The data has to be 23 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile 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>/kovaplus/roccatkovaplus<minor>/profile[1-5]_buttons
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
@@ -86,22 +52,6 @@ Description:	The mouse can store 5 profiles which can be switched by the
 		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_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 written, this file lets one write the respective profile
-		settings back to the mouse. The data has to be 16 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile 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>/kovaplus/roccatkovaplus<minor>/profile[1-5]_settings
 Date:		January 2011
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>

Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra

@@ -37,29 +37,6 @@ Description:	When read, this file returns the raw integer version number of the
 		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>/info
-Date:		November 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 6 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>/pyra/roccatpyra<minor>/profile_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 written, this file lets one write the respective profile
-		buttons back to the mouse. The data has to be 19 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile 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>/pyra/roccatpyra<minor>/profile[1-5]_buttons
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
@@ -72,22 +49,6 @@ Description:	The mouse can store 5 profiles which can be switched by the
 		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_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 written, this file lets one write the respective profile
-		settings back to the mouse. The data has to be 13 bytes long.
-		The mouse will reject invalid data.
-		Which profile to write is determined by the profile number
-		contained in the data.
-		Before reading this file, control has to be written to select
-		which profile 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>/pyra/roccatpyra<minor>/profile[1-5]_settings
 Date:		August 2010
 Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
@@ -101,17 +62,6 @@ Description:	The mouse can store 5 profiles which can be switched by the
 		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>/settings
-Date:		August 2010
-Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:	When read, this file returns the settings stored in the mouse.
-		The size of the data is 3 bytes and holds information on the
-		startup_profile.
-		When written, this file lets write settings back to the mouse.
-		The data has to be 3 bytes long. The mouse will reject invalid
-		data.
-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>

Documentation/ABI/stable/sysfs-bus-vmbus

@@ -1,29 +0,0 @@
-What:		/sys/bus/vmbus/devices/vmbus_*/id
-Date:		Jul 2009
-KernelVersion:	2.6.31
-Contact:	K. Y. Srinivasan <kys@microsoft.com>
-Description:	The VMBus child_relid of the device's primary channel
-Users:		tools/hv/lsvmbus
-
-What:		/sys/bus/vmbus/devices/vmbus_*/class_id
-Date:		Jul 2009
-KernelVersion:	2.6.31
-Contact:	K. Y. Srinivasan <kys@microsoft.com>
-Description:	The VMBus interface type GUID of the device
-Users:		tools/hv/lsvmbus
-
-What:		/sys/bus/vmbus/devices/vmbus_*/device_id
-Date:		Jul 2009
-KernelVersion:	2.6.31
-Contact:	K. Y. Srinivasan <kys@microsoft.com>
-Description:	The VMBus interface instance GUID of the device
-Users:		tools/hv/lsvmbus
-
-What:		/sys/bus/vmbus/devices/vmbus_*/channel_vp_mapping
-Date:		Jul 2015
-KernelVersion:	4.2.0
-Contact:	K. Y. Srinivasan <kys@microsoft.com>
-Description:	The mapping of which primary/sub channels are bound to which
-		Virtual Processors.
-		Format: <channel's child_relid:the bound cpu's number>
-Users:		tools/hv/lsvmbus

Documentation/ABI/stable/sysfs-bus-w1

@@ -1,11 +0,0 @@
-What:		/sys/bus/w1/devices/.../w1_master_timeout_us
-Date:		April 2015
-Contact:	Dmitry Khromov <dk@icelogic.net>
-Description:	Bus scanning interval, microseconds component.
-		Some of 1-Wire devices commonly associated with physical access
-		control systems are attached/generate presence for as short as
-		100 ms - hence the tens-to-hundreds milliseconds scan intervals
-		are required.
-		see Documentation/w1/w1.generic for detailed information.
-Users:		any user space application which wants to know bus scanning
-		interval

Documentation/ABI/stable/sysfs-class-tpm

@@ -116,7 +116,7 @@ Description:	The "pubek" property will return the TPM's public endorsement
 		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 manufacture time and exists for the life of the
+		ated at TPM menufacture time and exists for the life of the
 		chip.
 
 		Example output:
@@ -163,7 +163,7 @@ 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 deactivated, usually until the next power
+		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.
 

Documentation/ABI/stable/sysfs-devices

@@ -1,10 +0,0 @@
-# Note: This documents additional properties of any device beyond what
-# is documented in Documentation/sysfs-rules.txt
-
-What:		/sys/devices/*/of_path
-Date:		February 2015
-Contact:	Device Tree mailing list <devicetree@vger.kernel.org>
-Description:
-		Any device associated with a device-tree node will have
-		an of_path symlink pointing to the corresponding device
-		node in /sys/firmware/devicetree/

Documentation/ABI/stable/sysfs-driver-w1_ds28ea00

@@ -1,6 +0,0 @@
-What:		/sys/bus/w1/devices/.../w1_seq
-Date:		Apr 2015
-Contact:	Matt Campbell <mattrcampbell@gmail.com>
-Description:	Support for the DS28EA00 chain sequence function
-		see Documentation/w1/slaves/w1_therm for detailed information
-Users:		any user space application which wants to communicate with DS28EA00

Documentation/ABI/stable/sysfs-firmware-opal-elog

@@ -57,4 +57,4 @@ Description:
 				Shortly after acknowledging it, the log
 				entry will be removed from sysfs.
 				Reading this file will list the supported
-				operations (currently just acknowledge).
+				operations (curently just acknowledge).

Documentation/ABI/testing/configfs-spear-pcie-gadget

@@ -1,7 +1,7 @@
 What:		/config/pcie-gadget
 Date:		Feb 2011
 KernelVersion:	2.6.37
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 
 	Interface is used to configure selected dual mode PCIe controller

Documentation/ABI/testing/configfs-stp-policy

@@ -1,48 +0,0 @@
-What:		/config/stp-policy
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		This group contains policies mandating Master/Channel allocation
-		for software sources wishing to send trace data over an STM
-		device.
-
-What:		/config/stp-policy/<device>.<policy>
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		This group is the root of a policy; its name is a concatenation
-		of an stm device name to which this policy applies and an
-		arbitrary string. If <device> part doesn't match an existing
-		stm device, mkdir will fail with ENODEV; if that device already
-		has a policy assigned to it, mkdir will fail with EBUSY.
-
-What:		/config/stp-policy/<device>.<policy>/device
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		STM device to which this policy applies, read only. Same as the
-		<device> component of its parent directory.
-
-What:		/config/stp-policy/<device>.<policy>/<node>
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		Policy node is a string identifier that software clients will
-		use to request a master/channel to be allocated and assigned to
-		them.
-
-What:		/config/stp-policy/<device>.<policy>/<node>/masters
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		Range of masters from which to allocate for users of this node.
-		Write two numbers: the first master and the last master number.
-
-What:		/config/stp-policy/<device>.<policy>/<node>/channels
-Date:		June 2015
-KernelVersion:	4.3
-Description:
-		Range of channels from which to allocate for users of this node.
-		Write two numbers: the first channel and the last channel
-		number.
-

Documentation/ABI/testing/configfs-usb-gadget-loopback

@@ -5,4 +5,4 @@ Description:
 		The attributes:
 
 		qlen		- depth of loopback queue
-		buflen		- buffer length
+		bulk_buflen	- buffer length

Documentation/ABI/testing/configfs-usb-gadget-printer

@@ -1,9 +0,0 @@
-What:		/config/usb-gadget/gadget/functions/printer.name
-Date:		Apr 2015
-KernelVersion:	4.1
-Description:
-		The attributes:
-
-		pnp_string	- Data to be passed to the host in pnp string
-		q_len		- Number of requests per endpoint
-

Documentation/ABI/testing/configfs-usb-gadget-sourcesink

@@ -9,4 +9,4 @@ Description:
 		isoc_maxpacket	- 0 - 1023 (fs), 0 - 1024 (hs/ss)
 		isoc_mult	- 0..2 (hs/ss only)
 		isoc_maxburst	- 0..15 (ss only)
-		buflen		- buffer length
+		qlen		- buffer length

Documentation/ABI/testing/dev-kmsg

@@ -98,13 +98,4 @@ Description:	The /dev/kmsg character device node provides userspace access
 		logic is used internally when messages are printed to the
 		console, /proc/kmsg or the syslog() syscall.
 
-		By default, kernel tries to avoid fragments by concatenating
-		when it can and fragments are rare; however, when extended
-		console support is enabled, the in-kernel concatenation is
-		disabled and /dev/kmsg output will contain more fragments. If
-		the log consumer performs concatenation, the end result
-		should be the same. In the future, the in-kernel concatenation
-		may be removed entirely and /dev/kmsg users are recommended to
-		implement fragment handling.
-
 Users:		dmesg(1), userspace kernel log consumers

Documentation/ABI/testing/ima_policy

@@ -20,19 +20,17 @@ Description:
 		action: measure | dont_measure | appraise | dont_appraise | audit
 		condition:= base | lsm  [option]
 			base:	[[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
-				[euid=] [fowner=]]
+				 [fowner]]
 			lsm:	[[subj_user=] [subj_role=] [subj_type=]
 				 [obj_user=] [obj_role=] [obj_type=]]
 			option:	[[appraise_type=]] [permit_directio]
 
 		base: 	func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
 				[FIRMWARE_CHECK]
-			mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
-			       [[^]MAY_EXEC]
+			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
-			euid:= decimal value
 			fowner:=decimal value
 		lsm:  	are LSM specific
 		option:	appraise_type:= [imasig]
@@ -51,25 +49,11 @@ Description:
 			dont_measure fsmagic=0x01021994
 			dont_appraise fsmagic=0x01021994
 			# RAMFS_MAGIC
+			dont_measure fsmagic=0x858458f6
 			dont_appraise fsmagic=0x858458f6
-			# DEVPTS_SUPER_MAGIC
-			dont_measure fsmagic=0x1cd1
-			dont_appraise fsmagic=0x1cd1
-			# BINFMTFS_MAGIC
-			dont_measure fsmagic=0x42494e4d
-			dont_appraise fsmagic=0x42494e4d
 			# SECURITYFS_MAGIC
 			dont_measure fsmagic=0x73636673
 			dont_appraise fsmagic=0x73636673
-			# SELINUX_MAGIC
-			dont_measure fsmagic=0xf97cff8c
-			dont_appraise fsmagic=0xf97cff8c
-			# CGROUP_SUPER_MAGIC
-			dont_measure fsmagic=0x27e0eb
-			dont_appraise fsmagic=0x27e0eb
-			# NSFS_MAGIC
-			dont_measure fsmagic=0x6e736673
-			dont_appraise fsmagic=0x6e736673
 
 			measure func=BPRM_CHECK
 			measure func=FILE_MMAP mask=MAY_EXEC
@@ -86,6 +70,10 @@ Description:
 		Examples of LSM specific definitions:
 
 		SELinux:
+			# SELINUX_MAGIC
+			dont_measure fsmagic=0xf97cff8c
+			dont_appraise fsmagic=0xf97cff8c
+
 			dont_measure obj_type=var_log_t
 			dont_appraise obj_type=var_log_t
 			dont_measure obj_type=auditd_log_t

Documentation/ABI/testing/sysfs-ata

@@ -90,17 +90,6 @@ gscr
 	130:	SATA_PMP_GSCR_SII_GPIO
 	Only valid if the device is a PM.
 
-trim
-
-	Shows the DSM TRIM mode currently used by the device. Valid
-	values are:
-	unsupported:		Drive does not support DSM TRIM
-	unqueued:		Drive supports unqueued DSM TRIM only
-	queued:			Drive supports queued DSM TRIM
-	forced_unqueued:	Drive's queued DSM support is known to be
-				buggy and only unqueued TRIM commands
-				are sent
-
 spdn_cnt
 
 	Number of time libata decided to lower the speed of link due to errors.

Documentation/ABI/testing/sysfs-block

@@ -60,13 +60,6 @@ Description:
 		Indicates whether a storage device is capable of storing
 		integrity metadata. Set if the device is T10 PI-capable.
 
-What:		/sys/block/<disk>/integrity/protection_interval_bytes
-Date:		July 2015
-Contact:	Martin K. Petersen <martin.petersen@oracle.com>
-Description:
-		Describes the number of data bytes which are protected
-		by one integrity tuple. Typically the device's logical
-		block size.
 
 What:		/sys/block/<disk>/integrity/write_generate
 Date:		June 2008

Documentation/ABI/testing/sysfs-block-dm

@@ -23,25 +23,3 @@ Description:	Device-mapper device suspend state.
 		Contains the value 1 while the device is suspended.
 		Otherwise it contains 0. Read-only attribute.
 Users:		util-linux, device-mapper udev rules
-
-What:		/sys/block/dm-<num>/dm/rq_based_seq_io_merge_deadline
-Date:		March 2015
-KernelVersion:	4.1
-Contact:	dm-devel@redhat.com
-Description:	Allow control over how long a request that is a
-		reasonable merge candidate can be queued on the request
-		queue.  The resolution of this deadline is in
-		microseconds (ranging from 1 to 100000 usecs).
-		Setting this attribute to 0 (the default) will disable
-		request-based DM's merge heuristic and associated extra
-		accounting.  This attribute is not applicable to
-		bio-based DM devices so it will only ever report 0 for
-		them.
-
-What:		/sys/block/dm-<num>/dm/use_blk_mq
-Date:		March 2015
-KernelVersion:	4.1
-Contact:	dm-devel@redhat.com
-Description:	Request-based Device-mapper blk-mq I/O path mode.
-		Contains the value 1 if the device is using blk-mq.
-		Otherwise it contains 0. Read-only attribute.

Documentation/ABI/testing/sysfs-block-zram

@@ -141,28 +141,3 @@ Description:
 		amount of memory ZRAM can use to store the compressed data.  The
 		limit could be changed in run time and "0" means disable the
 		limit.  No limit is the initial state.  Unit: bytes
-
-What:		/sys/block/zram<id>/compact
-Date:		August 2015
-Contact:	Minchan Kim <minchan@kernel.org>
-Description:
-		The compact file is write-only and trigger compaction for
-		allocator zrm uses. The allocator moves some objects so that
-		it could free fragment space.
-
-What:		/sys/block/zram<id>/io_stat
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The io_stat file is read-only and accumulates device's I/O
-		statistics not accounted by block layer. For example,
-		failed_reads, failed_writes, etc. File format is similar to
-		block layer statistics file format.
-
-What:		/sys/block/zram<id>/mm_stat
-Date:		August 2015
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The mm_stat file is read-only and represents device's mm
-		statistics (orig_data_size, compr_data_size, etc.) in a format
-		similar to block layer statistics file format.

Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x

@@ -8,6 +8,13 @@ Description:	(RW) Enable/disable tracing on this specific trace entiry.
 		of coresight components linking the source to the sink is
 		configured and managed automatically by the coresight framework.
 
+What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/status
+Date:		November 2014
+KernelVersion:	3.19
+Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
+Description:	(R) List various control and status registers.  The specific
+		layout and content is driver specific.
+
 What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_idx
 Date:		November 2014
 KernelVersion:	3.19
@@ -105,7 +112,7 @@ KernelVersion:	3.19
 Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
 Description: 	(RW) Mask to apply to all the context ID comparator.
 
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_pid
+What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_val
 Date:		November 2014
 KernelVersion:	3.19
 Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
@@ -244,79 +251,3 @@ Date:		November 2014
 KernelVersion:	3.19
 Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
 Description: 	(RW) Define the event that controls the trigger.
-
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cpu
-Date:		October 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RO) Holds the cpu number this tracer is affined to.
-
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmccr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Configuration Code register
-		(0x004).  The value is read directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmccer
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Configuration Code Extension
-		register (0x1e8).  The value is read directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmscr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM System Configuration
-		register (0x014).  The value is read directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmidr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM ID register (0x1e4).  The
-		value is read directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmcr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Main Control register (0x000).
-		The value is read directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtraceidr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Trace ID register (0x200).
-		The value is read directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmteevr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Trace Enable Event register
-		(0x020). The value is read directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtsscr
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Trace Start/Stop Conrol
-		register (0x018). The value is read directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr1
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Enable Conrol #1
-		register (0x024). The value is read directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr2
-Date:		September 2015
-KernelVersion:	4.4
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RO) Print the content of the ETM Enable Conrol #2
-		register (0x01c). The value is read directly from the HW.

Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x

@@ -1,450 +0,0 @@
-What:		/sys/bus/coresight/devices/<memory_map>.etm/enable_source
-Date:		April 2015
-KernelVersion:  4.01
-Contact:        Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Enable/disable tracing on this specific trace entiry.
-		Enabling a source implies the source has been configured
-		properly and a sink has been identidifed for it.  The path
-		of coresight components linking the source to the sink is
-		configured and managed automatically by the coresight framework.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cpu
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) The CPU this tracing entity is associated with.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_pe_cmp
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of PE comparator inputs that are
-		available for tracing.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_addr_cmp
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of address comparator pairs that are
-		available for tracing.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_cntr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of counters that are available for
-		tracing.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_ext_inp
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates how many external inputs are implemented.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/numcidc
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of Context ID comparators that are
-		available for tracing.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/numvmidc
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of VMID comparators that are available
-		for tracing.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nrseqstate
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of sequencer states that are
-		implemented.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_resource
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of resource selection pairs that are
-		available for tracing.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/nr_ss_cmp
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Indicates the number of single-shot comparator controls that
-		are available for tracing.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/reset
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(W) Cancels all configuration on a trace unit and set it back
-		to its boot configuration.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mode
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls various modes supported by this ETM, for example
-		P0 instruction tracing, branch broadcast, cycle counting and
-		context ID tracing.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/pe
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls which PE to trace.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/event
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls the tracing of arbitrary events from bank 0 to 3.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/event_instren
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls the behavior of the events in bank 0 to 3.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/event_ts
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls the insertion of global timestamps in the trace
-		streams.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/syncfreq
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls how often trace synchronization requests occur.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cyc_threshold
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Sets the threshold value for cycle counting.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/bb_ctrl
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls which regions in the memory map are enabled to
-		use branch broadcasting.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/event_vinst
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls instruction trace filtering.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/s_exlevel_vinst
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) In Secure state, each bit controls whether instruction
-		tracing is enabled for the corresponding exception level.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/ns_exlevel_vinst
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) In non-secure state, each bit controls whether instruction
-		tracing is enabled for the corresponding exception level.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/addr_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Select which address comparator or pair (of comparators) to
-		work with.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/addr_instdatatype
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls what type of comparison the trace unit performs.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/addr_single
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Used to setup single address comparator values.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/addr_range
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Used to setup address range comparator values.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/seq_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Select which sequensor.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/seq_state
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Use this to set, or read, the sequencer state.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/seq_event
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Moves the sequencer state to a specific state.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/seq_reset_event
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Moves the sequencer to state 0 when a programmed event
-		occurs.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cntr_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Select which counter unit to work with.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cntrldvr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) This sets or returns the reload count value of the
-		specific counter.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cntr_val
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) This sets or returns the current count value of the
-                specific counter.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/cntr_ctrl
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls the operation of the selected counter.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/res_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Select which resource selection unit to work with.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/res_ctrl
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: 	(RW) Controls the selection of the resources in the trace unit.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/ctxid_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Select which context ID comparator to work with.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/ctxid_pid
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Get/Set the context ID comparator value to trigger on.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/ctxid_masks
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Mask for all 8 context ID comparator value
-		registers (if implemented).
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/vmid_idx
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Select which virtual machine ID comparator to work with.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/vmid_val
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Get/Set the virtual machine ID comparator value to
-		trigger on.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/vmid_masks
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(RW) Mask for all 8 virtual machine ID comparator value
-		registers (if implemented).
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcoslsr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the OS Lock Status Register (0x304).
-		The value it taken directly  from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdcr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Power Down Control Register
-		(0x310).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdsr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Power Down Status Register
-		(0x314).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trclsr
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the SW Lock Status Register
-		(0xFB4).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcauthstatus
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Authentication Status Register
-		(0xFB8).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevid
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Device ID Register
-		(0xFC8).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevtype
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Device Type Register
-		(0xFCC).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr0
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Peripheral ID0 Register
-		(0xFE0).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr1
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Peripheral ID1 Register
-		(0xFE4).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr2
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Peripheral ID2 Register
-		(0xFE8).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr3
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Print the content of the Peripheral ID3 Register
-		(0xFEC).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr0
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the tracing capabilities of the trace unit (0x1E0).
-		The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr1
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the tracing capabilities of the trace unit (0x1E4).
-		The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr2
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the maximum size of the data value, data address,
-		VMID, context ID and instuction address in the trace unit
-		(0x1E8).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr3
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the value associated with various resources
-		available to the trace unit.  See the Trace Macrocell
-		architecture specification for more details (0x1E8).
-		The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr4
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns how many resources the trace unit supports (0x1F0).
-		The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr5
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns how many resources the trace unit supports (0x1F4).
-		The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr8
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the maximum speculation depth of the instruction
-		trace stream. (0x180).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr9
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the number of P0 right-hand keys that the trace unit
-		can use (0x184).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr10
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the number of P1 right-hand keys that the trace unit
-		can use (0x188).  The value is taken directly from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr11
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the number of special P1 right-hand keys that the
-		trace unit can use (0x18C).  The value is taken directly from
-		the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr12
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the number of conditional P1 right-hand keys that
-		the trace unit can use (0x190).  The value is taken directly
-		from the HW.
-
-What:		/sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr13
-Date:		April 2015
-KernelVersion:	4.01
-Contact:	Mathieu Poirier <mathieu.poirier@linaro.org>
-Description:	(R) Returns the number of special conditional P1 right-hand keys
-		that the trace unit can use (0x194).  The value is taken
-		directly from the HW.

Documentation/ABI/testing/sysfs-bus-fcoe

@@ -32,7 +32,7 @@ Description:	'FCoE Controller' instances on the fcoe bus.
 
 Attributes:
 
-	fcf_dev_loss_tmo: Device loss timeout period (see below). Changing
+	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.
 
@@ -61,7 +61,7 @@ Attributes:
 	lesb/err_block:   Link Error Status Block (LESB) block error count.
 
 	lesb/fcs_error:   Link Error Status Block (LESB) Fibre Channel
-			  Services error count.
+			  Serivces error count.
 
 Notes: ctlr_X (global increment starting at 0)
 
@@ -85,7 +85,7 @@ Attributes:
 		     fabric.
 
 	selected:    1 indicates that the switch has been selected for use;
-		     0 indicates that the switch will not be used.
+		     0 indicates that the swich will not be used.
 
 	fc_map:      The Fibre Channel MAP
 
@@ -93,7 +93,7 @@ Attributes:
 
 	mac:         The FCF's MAC address
 
-	fka_period:  The FIP Keep-Alive period
+	fka_peroid:  The FIP Keep-Alive peroid
 
 	fabric_state: The internal kernel state
 		      "Unknown" - Initialization value
@@ -101,9 +101,9 @@ Attributes:
 		      "Connected" - Host is connected to the FCF
 		      "Deleted" - FCF is being removed from the system
 
-	dev_loss_tmo: The device loss timeout period for this FCF.
+	dev_loss_tmo: The device loss timeout peroid for this FCF.
 
-Notes: A device loss infrastructure similar to the FC Transport's
+Notes: A device loss infrastructre similar to the FC Transport's
        is present in fcoe_sysfs. It is nice to have so that a
        link flapping adapter doesn't continually advance the count
        used to identify the discovered FCF. FCFs will exist in a

Documentation/ABI/testing/sysfs-bus-iio

@@ -71,8 +71,6 @@ Description:
 
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_raw
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_i_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_q_raw
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -83,11 +81,6 @@ Description:
 		unique to allow association with event codes. Units after
 		application of scale and offset are millivolts.
 
-		Channels with 'i' and 'q' modifiers always exist in pairs and both
-		channels refer to the same signal. The 'i' channel contains the in-phase
-		component of the signal while the 'q' channel contains the quadrature
-		component.
-
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_raw
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
@@ -253,23 +246,13 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_accel_y_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_accel_z_offset
 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_voltageY_i_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_q_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_q_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_i_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_offset
 What:		/sys/bus/iio/devices/iio:deviceX/in_current_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_i_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_q_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_current_q_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_current_i_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
 What:		/sys/bus/iio/devices/iio:deviceX/in_humidityrelative_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_magn_offset
-What:		/sys/bus/iio/devices/iio:deviceX/in_rot_offset
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -288,22 +271,14 @@ Description:
 		to the _raw output.
 
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_i_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_q_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_i_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltage_q_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_scale
 What:		/sys/bus/iio/devices/iio:deviceX/out_voltageY_scale
 What:		/sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_supply_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_current_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_i_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentY_q_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_current_i_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_current_q_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_accel_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
@@ -321,7 +296,6 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_pressure_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale
-What:		/sys/bus/iio/devices/iio:deviceX/in_illuminance_scale
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -351,10 +325,6 @@ Description:
 
 What		/sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale
 What		/sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale
-What		/sys/bus/iio/devices/iio:deviceX/in_voltageY_i_calibscale
-What		/sys/bus/iio/devices/iio:deviceX/in_voltageY_q_calibscale
-What		/sys/bus/iio/devices/iio:deviceX/in_voltage_i_calibscale
-What		/sys/bus/iio/devices/iio:deviceX/in_voltage_q_calibscale
 What		/sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale
 What		/sys/bus/iio/devices/iio:deviceX/in_accel_x_calibscale
 What		/sys/bus/iio/devices/iio:deviceX/in_accel_y_calibscale
@@ -366,7 +336,6 @@ 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
-What:		/sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -378,7 +347,7 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_activity_calibgender
 What:		/sys/bus/iio/devices/iio:deviceX/in_energy_calibgender
 What:		/sys/bus/iio/devices/iio:deviceX/in_distance_calibgender
 What:		/sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender
-KernelVersion:	4.0
+KernelVersion:	3.20
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Gender of the user (e.g.: male, female) used by some pedometers
@@ -389,7 +358,7 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_activity_calibgender_available
 What:		/sys/bus/iio/devices/iio:deviceX/in_energy_calibgender_available
 What:		/sys/bus/iio/devices/iio:deviceX/in_distance_calibgender_available
 What:		/sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender_available
-KernelVersion:	4.0
+KernelVersion:	3.20
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Lists all available gender values (e.g.: male, female).
@@ -406,18 +375,13 @@ Description:
 		type.
 
 What:		/sys/bus/iio/devices/iio:deviceX/in_energy_calibweight
-KernelVersion:	4.0
+KernelVersion:	3.20
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Weight of the user (in kg). It is needed by some pedometers
 		to compute the calories burnt by the user.
 
 What:		/sys/bus/iio/devices/iio:deviceX/in_accel_scale_available
-What:		/sys/.../iio:deviceX/in_anglvel_scale_available
-What:		/sys/.../iio:deviceX/in_magn_scale_available
-What:		/sys/.../iio:deviceX/in_illuminance_scale_available
-What:		/sys/.../iio:deviceX/in_intensity_scale_available
-What:		/sys/.../iio:deviceX/in_proximity_scale_available
 What:		/sys/.../iio:deviceX/in_voltageX_scale_available
 What:		/sys/.../iio:deviceX/in_voltage-voltage_scale_available
 What:		/sys/.../iio:deviceX/out_voltageX_scale_available
@@ -452,16 +416,6 @@ Description:
 		to the underlying data channel, then this parameter
 		gives the 3dB frequency of the filter in Hz.
 
-What:		/sys/.../in_accel_filter_high_pass_3db_frequency
-What:		/sys/.../in_anglvel_filter_high_pass_3db_frequency
-What:		/sys/.../in_magn_filter_high_pass_3db_frequency
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		If a known or controllable high pass filter is applied
-		to the underlying data channel, then this parameter
-		gives the 3dB frequency of the filter in Hz.
-
 What:		/sys/bus/iio/devices/iio:deviceX/out_voltageY_raw
 What:		/sys/bus/iio/devices/iio:deviceX/out_altvoltageY_raw
 KernelVersion:	2.6.37
@@ -493,7 +447,7 @@ Contact:	linux-iio@vger.kernel.org
 Description:
 		Specifies the output powerdown mode.
 		DAC output stage is disconnected from the amplifier and
-		1kohm_to_gnd: connected to ground via an 1kOhm resistor,
+		1kohm_to_gnd: connected	to ground via an 1kOhm resistor,
 		6kohm_to_gnd: connected to ground via a 6kOhm resistor,
 		20kohm_to_gnd: connected to ground via a 20kOhm resistor,
 		100kohm_to_gnd: connected to ground via an 100kOhm resistor,
@@ -503,9 +457,9 @@ Description:
 		outX_powerdown_mode_available. If Y is not present the
 		mode is shared across all outputs.
 
-What:		/sys/.../iio:deviceX/out_voltageY_powerdown_mode_available
+What:		/sys/.../iio:deviceX/out_votlageY_powerdown_mode_available
 What:		/sys/.../iio:deviceX/out_voltage_powerdown_mode_available
-What:		/sys/.../iio:deviceX/out_altvoltageY_powerdown_mode_available
+What:		/sys/.../iio:deviceX/out_altvotlageY_powerdown_mode_available
 What:		/sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available
 KernelVersion:	2.6.38
 Contact:	linux-iio@vger.kernel.org
@@ -581,7 +535,6 @@ What:		/sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
 What:		/sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
 What:		/sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
 What:		/sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en
-What:		/sys/.../iio:deviceX/events/in_voltageY_thresh_either_en
 What:		/sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
 What:		/sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
 KernelVersion:	2.6.37
@@ -659,8 +612,6 @@ Description:
 		a given event type is enabled a future point (and not those for
 		whatever event was previously enabled).
 
-What:		/sys/.../events/in_accel_thresh_rising_value
-What:		/sys/.../events/in_accel_thresh_falling_value
 What:		/sys/.../events/in_accel_x_raw_thresh_rising_value
 What:		/sys/.../events/in_accel_x_raw_thresh_falling_value
 What:		/sys/.../events/in_accel_y_raw_thresh_rising_value
@@ -710,24 +661,6 @@ Description:
 		value is in raw device units or in processed units (as _raw
 		and _input do on sysfs direct channel read attributes).
 
-What:		/sys/.../events/in_accel_scale
-What:		/sys/.../events/in_accel_peak_scale
-What:		/sys/.../events/in_anglvel_scale
-What:		/sys/.../events/in_magn_scale
-What:		/sys/.../events/in_rot_from_north_magnetic_scale
-What:		/sys/.../events/in_rot_from_north_true_scale
-What:		/sys/.../events/in_voltage_scale
-What:		/sys/.../events/in_voltage_supply_scale
-What:		/sys/.../events/in_temp_scale
-What:		/sys/.../events/in_illuminance_scale
-What:		/sys/.../events/in_proximity_scale
-KernelVersion:	3.21
-Contact:	linux-iio@vger.kernel.org
-Description:
-                Specifies the conversion factor from the standard units
-                to device specific units used to set the event trigger
-                threshold.
-
 What:		/sys/.../events/in_accel_x_thresh_rising_hysteresis
 What:		/sys/.../events/in_accel_x_thresh_falling_hysteresis
 What:		/sys/.../events/in_accel_x_thresh_either_hysteresis
@@ -843,7 +776,7 @@ Description:
 
 What:		/sys/.../events/in_accel_x_thresh_rising_period
 What:		/sys/.../events/in_accel_x_thresh_falling_period
-What:		/sys/.../events/in_accel_x_roc_rising_period
+hat:		/sys/.../events/in_accel_x_roc_rising_period
 What:		/sys/.../events/in_accel_x_roc_falling_period
 What:		/sys/.../events/in_accel_y_thresh_rising_period
 What:		/sys/.../events/in_accel_y_thresh_falling_period
@@ -923,26 +856,6 @@ Description:
 		met before an event is generated. If direction is not
 		specified then this period applies to both directions.
 
-What:		/sys/.../events/in_accel_thresh_rising_low_pass_filter_3db
-What:		/sys/.../events/in_anglvel_thresh_rising_low_pass_filter_3db
-What:		/sys/.../events/in_magn_thresh_rising_low_pass_filter_3db
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		If a low pass filter can be applied to the event generation
-		this property gives its 3db frequency in Hz.
-		A value of zero disables the filter.
-
-What:		/sys/.../events/in_accel_thresh_rising_high_pass_filter_3db
-What:		/sys/.../events/in_anglvel_thresh_rising_high_pass_filter_3db
-What:		/sys/.../events/in_magn_thresh_rising_high_pass_filter_3db
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		If a high pass filter can be applied to the event generation
-		this property gives its 3db frequency in Hz.
-		A value of zero disables the filter.
-
 What:		/sys/.../events/in_activity_still_thresh_rising_en
 What:		/sys/.../events/in_activity_still_thresh_falling_en
 What:		/sys/.../events/in_activity_walking_thresh_rising_en
@@ -1010,7 +923,7 @@ Description:
 		this type.
 
 What:		/sys/.../events/in_steps_change_en
-KernelVersion:	4.0
+KernelVersion:	3.20
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Event generated when channel passes a threshold on the absolute
@@ -1019,7 +932,7 @@ Description:
 		in_steps_change_value.
 
 What:		/sys/.../events/in_steps_change_value
-KernelVersion:	4.0
+KernelVersion:	3.20
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Specifies the value of change threshold that the
@@ -1041,6 +954,13 @@ Contact:	linux-iio@vger.kernel.org
 Description:
 		Number of scans contained by the buffer.
 
+What:		/sys/bus/iio/devices/iio:deviceX/buffer/bytes_per_datum
+KernelVersion:	2.6.37
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Bytes per scan.  Due to alignment fun, the scan may be larger
+		than implied directly by the scan_element parameters.
+
 What:		/sys/bus/iio/devices/iio:deviceX/buffer/enable
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
@@ -1072,16 +992,11 @@ What:		/sys/.../iio:deviceX/scan_elements/in_timestamp_en
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_en
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_i_en
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_q_en
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_i_en
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_q_en
 What:		/sys/.../iio:deviceX/scan_elements/in_incli_x_en
 What:		/sys/.../iio:deviceX/scan_elements/in_incli_y_en
 What:		/sys/.../iio:deviceX/scan_elements/in_pressureY_en
 What:		/sys/.../iio:deviceX/scan_elements/in_pressure_en
 What:		/sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en
-What:		/sys/.../iio:deviceX/scan_elements/in_proximity_en
 KernelVersion:	2.6.37
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -1094,15 +1009,10 @@ What:		/sys/.../iio:deviceX/scan_elements/in_incli_type
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_type
 What:		/sys/.../iio:deviceX/scan_elements/in_voltage_type
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_i_type
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_q_type
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_i_type
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_q_type
 What:		/sys/.../iio:deviceX/scan_elements/in_timestamp_type
 What:		/sys/.../iio:deviceX/scan_elements/in_pressureY_type
 What:		/sys/.../iio:deviceX/scan_elements/in_pressure_type
 What:		/sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type
-What:		/sys/.../iio:deviceX/scan_elements/in_proximity_type
 KernelVersion:	2.6.37
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -1135,10 +1045,6 @@ Description:
 
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_index
 What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_i_index
-What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_q_index
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_i_index
-What:		/sys/.../iio:deviceX/scan_elements/in_voltage_q_index
 What:		/sys/.../iio:deviceX/scan_elements/in_accel_x_index
 What:		/sys/.../iio:deviceX/scan_elements/in_accel_y_index
 What:		/sys/.../iio:deviceX/scan_elements/in_accel_z_index
@@ -1158,7 +1064,6 @@ What:		/sys/.../iio:deviceX/scan_elements/in_timestamp_index
 What:		/sys/.../iio:deviceX/scan_elements/in_pressureY_index
 What:		/sys/.../iio:deviceX/scan_elements/in_pressure_index
 What:		/sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index
-What:		/sys/.../iio:deviceX/scan_elements/in_proximity_index
 KernelVersion:	2.6.37
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -1199,7 +1104,7 @@ Description:
 
 What:		/sys/.../iio:deviceX/in_energy_input
 What:		/sys/.../iio:deviceX/in_energy_raw
-KernelVersion:	4.0
+KernelVersion:	3.20
 Contact:	linux-iio@vger.kernel.org
 Description:
 		This attribute is used to read the energy value reported by the
@@ -1208,7 +1113,7 @@ Description:
 
 What:		/sys/.../iio:deviceX/in_distance_input
 What:		/sys/.../iio:deviceX/in_distance_raw
-KernelVersion:	4.0
+KernelVersion:	3.20
 Contact:	linux-iio@vger.kernel.org
 Description:
 		This attribute is used to read the distance covered by the user
@@ -1233,16 +1138,14 @@ Description:
 		object is near the sensor, usually be observing
 		reflectivity of infrared or ultrasound emitted.
 		Often these sensors are unit less and as such conversion
-		to SI units is not possible. Higher proximity measurements
-		indicate closer objects, and vice versa.
+		to SI units is not possible.  Where it is, the units should
+		be meters.  If such a conversion is not possible, the reported
+		values should behave in the same way as a distance, i.e. lower
+		values indicate something is closer to the sensor.
 
-What:		/sys/.../iio:deviceX/in_illuminance_input
-What:		/sys/.../iio:deviceX/in_illuminance_raw
 What:		/sys/.../iio:deviceX/in_illuminanceY_input
 What:		/sys/.../iio:deviceX/in_illuminanceY_raw
 What:		/sys/.../iio:deviceX/in_illuminanceY_mean_raw
-What:		/sys/.../iio:deviceX/in_illuminance_ir_raw
-What:		/sys/.../iio:deviceX/in_illuminance_clear_raw
 KernelVersion:	3.4
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -1271,7 +1174,7 @@ Description:
 		seconds.
 
 What:		/sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_integration_time
-KernelVersion:	4.0
+KernelVersion:	3.20
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Number of seconds in which to compute speed.
@@ -1296,8 +1199,6 @@ Description:
 		or without compensation from tilt sensors.
 
 What:		/sys/bus/iio/devices/iio:deviceX/in_currentX_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentX_i_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_currentX_q_raw
 KernelVersion:	3.18
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -1306,11 +1207,6 @@ Description:
 		present, output should be considered as processed with the
 		unit in milliamps.
 
-		Channels with 'i' and 'q' modifiers always exist in pairs and both
-		channels refer to the same signal. The 'i' channel contains the in-phase
-		component of the signal while the 'q' channel contains the quadrature
-		component.
-
 What:		/sys/.../iio:deviceX/in_energy_en
 What:		/sys/.../iio:deviceX/in_distance_en
 What:		/sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_en
@@ -1340,7 +1236,7 @@ Description:
 		Units after application of scale are m/s.
 
 What:		/sys/.../iio:deviceX/in_steps_debounce_count
-KernelVersion:	4.0
+KernelVersion:	3.20
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Specifies the number of steps that must occur within
@@ -1348,146 +1244,8 @@ Description:
 		consumer is making steps.
 
 What:		/sys/.../iio:deviceX/in_steps_debounce_time
-KernelVersion:	4.0
+KernelVersion:	3.20
 Contact:	linux-iio@vger.kernel.org
 Description:
 		Specifies number of seconds in which we compute the steps
 		that occur in order to decide if the consumer is making steps.
-
-What:		/sys/bus/iio/devices/iio:deviceX/buffer/watermark
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		A single positive integer specifying the maximum number of scan
-		elements to wait for.
-		Poll will block until the watermark is reached.
-		Blocking read will wait until the minimum between the requested
-		read amount or the low water mark is available.
-		Non-blocking read will retrieve the available samples from the
-		buffer even if there are less samples then watermark level. This
-		allows the application to block on poll with a timeout and read
-		the available samples after the timeout expires and thus have a
-		maximum delay guarantee.
-
-What:		/sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_enabled
-KernelVersion: 4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		A read-only boolean value that indicates if the hardware fifo is
-		currently enabled or disabled. If the device does not have a
-		hardware fifo this entry is not present.
-		The hardware fifo is enabled when the buffer is enabled if the
-		current hardware fifo watermark level is set and other current
-		device settings allows it (e.g. if a trigger is set that samples
-		data differently that the hardware fifo does then hardware fifo
-		will not enabled).
-		If the hardware fifo is enabled and the level of the hardware
-		fifo reaches the hardware fifo watermark level the device will
-		flush its hardware fifo to the device buffer. Doing a non
-		blocking read on the device when no samples are present in the
-		device buffer will also force a flush.
-		When the hardware fifo is enabled there is no need to use a
-		trigger to use buffer mode since the watermark settings
-		guarantees that the hardware fifo is flushed to the device
-		buffer.
-
-What:		/sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark
-KernelVersion: 4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Read-only entry that contains a single integer specifying the
-		current watermark level for the hardware fifo. If the device
-		does not have a hardware fifo this entry is not present.
-		The watermark level for the hardware fifo is set by the driver
-		based on the value set by the user in buffer/watermark but
-		taking into account hardware limitations (e.g. most hardware
-		buffers are limited to 32-64 samples, some hardware buffers
-		watermarks are fixed or have minimum levels).  A value of 0
-		means that the hardware watermark is unset.
-
-What:		/sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_min
-KernelVersion: 4.2
-Contact:       linux-iio@vger.kernel.org
-Description:
-		A single positive integer specifying the minimum watermark level
-		for the hardware fifo of this device. If the device does not
-		have a hardware fifo this entry is not present.
-		If the user sets buffer/watermark to a value less than this one,
-		then the hardware watermark will remain unset.
-
-What:	       /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_max
-KernelVersion: 4.2
-Contact:       linux-iio@vger.kernel.org
-Description:
-		A single positive integer specifying the maximum watermark level
-		for the hardware fifo of this device. If the device does not
-		have a hardware fifo this entry is not present.
-		If the user sets buffer/watermark to a value greater than this
-		one, then the hardware watermark will be capped at this value.
-
-What:	       /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_available
-KernelVersion: 4.2
-Contact:       linux-iio@vger.kernel.org
-Description:
-		A list of positive integers specifying the available watermark
-		levels for the hardware fifo. This entry is optional and if it
-		is not present it means that all the values between
-		hwfifo_watermark_min and hwfifo_watermark_max are supported.
-		If the user sets buffer/watermark to a value greater than
-		hwfifo_watermak_min but not equal to any of the values in this
-		list, the driver will chose an appropriate value for the
-		hardware fifo watermark level.
-
-What:		/sys/bus/iio/devices/iio:deviceX/in_temp_calibemissivity
-What:		/sys/bus/iio/devices/iio:deviceX/in_tempX_calibemissivity
-What:		/sys/bus/iio/devices/iio:deviceX/in_temp_object_calibemissivity
-What:		/sys/bus/iio/devices/iio:deviceX/in_tempX_object_calibemissivity
-KernelVersion:	4.1
-Contact:	linux-iio@vger.kernel.org
-Description:
-		The emissivity ratio of the surface in the field of view of the
-		contactless temperature sensor.  Emissivity varies from 0 to 1,
-		with 1 being the emissivity of a black body.
-
-What:		/sys/bus/iio/devices/iio:deviceX/in_magn_x_oversampling_ratio
-What:		/sys/bus/iio/devices/iio:deviceX/in_magn_y_oversampling_ratio
-What:		/sys/bus/iio/devices/iio:deviceX/in_magn_z_oversampling_ratio
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Hardware applied number of measurements for acquiring one
-		data point. The HW will do <type>[_name]_oversampling_ratio
-		measurements and return the average value as output data. Each
-		value resulted from <type>[_name]_oversampling_ratio measurements
-		is considered as one sample for <type>[_name]_sampling_frequency.
-
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentration_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentration_co2_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentrationX_co2_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentration_voc_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw
-KernelVersion:	4.3
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Raw (unscaled no offset etc.) percentage reading of a substance.
-
-What:		/sys/bus/iio/devices/iio:deviceX/in_resistance_raw
-What:		/sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw
-What:		/sys/bus/iio/devices/iio:deviceX/out_resistance_raw
-What:		/sys/bus/iio/devices/iio:deviceX/out_resistanceX_raw
-KernelVersion:	4.3
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Raw (unscaled no offset etc.) resistance reading that can be processed
-		into an ohm value.
-
-What:		/sys/bus/iio/devices/iio:deviceX/heater_enable
-KernelVersion:	4.1.0
-Contact:	linux-iio@vger.kernel.org
-Description:
-		'1' (enable) or '0' (disable) specifying the enable
-		of heater function. Same reading values apply
-		This ABI is especially applicable for humidity sensors
-		to heatup the device and get rid of any condensation
-		in some humidity environment

Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435

@@ -1,43 +0,0 @@
-What:		/sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode
-Date:		August 2015
-KernelVersion:	4.2.0
-Contact:	source@cogentembedded.com
-Description:
-		Program sensor type for threshold detector inputs.
-		Could be either "GND-Open" or "Supply-Open" mode. Y is a
-		threshold detector input channel. Channels 0..7, 8..15, 16..23
-		and 24..31 has common sensor types.
-
-What:		/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value
-Date:		August 2015
-KernelVersion:	4.2.0
-Contact:	source@cogentembedded.com
-Description:
-		Channel Y low voltage threshold. If sensor input voltage goes lower then
-		this value then the threshold falling event is pushed.
-		Depending on in_voltageY_sensing_mode the low voltage threshold
-		is separately set for "GND-Open" and "Supply-Open" modes.
-		Channels 0..31 have common low threshold values, but could have different
-		sensing_modes.
-		The low voltage threshold range is between 2..21V.
-		Hysteresis between low and high thresholds can not be lower then 2 and
-		can not be odd.
-		If falling threshold results hysteresis to odd value then rising
-		threshold is automatically subtracted by one.
-
-What:		/sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_rising_value
-Date:		August 2015
-KernelVersion:	4.2.0
-Contact:	source@cogentembedded.com
-Description:
-		Channel Y high voltage threshold. If sensor input voltage goes higher then
-		this value then the threshold rising event is pushed.
-		Depending on in_voltageY_sensing_mode the high voltage threshold
-		is separately set for "GND-Open" and "Supply-Open" modes.
-		Channels 0..31 have common high threshold values, but could have different
-		sensing_modes.
-		The high voltage threshold range is between 3..22V.
-		Hysteresis between low and high thresholds can not be lower then 2 and
-		can not be odd.
-		If rising threshold results hysteresis to odd value then falling
-		threshold is automatically appended by one.

Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x

@@ -1,7 +0,0 @@
-What:		/sys/bus/iio/devices/iio:deviceX/in_concentration_VOC_short_raw
-Date:		September 2015
-KernelVersion:	4.3
-Contact:	Matt Ranostay <mranostay@gmail.com>
-Description:
-		Get the raw calibration VOC value from the sensor.
-		This value has little application outside of calibration.

Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x

@@ -1,9 +0,0 @@
-What:		/sys/bus/iio/devices/iio:deviceX/out_current_heater_raw
-What:		/sys/bus/iio/devices/iio:deviceX/out_current_heater_raw_available
-KernelVersion:	4.3
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Controls the heater device within the humidity sensor to get
-		rid of excess condensation.
-
-		Valid control values are 0 = OFF, and 1 = ON.

Documentation/ABI/testing/sysfs-bus-iio-meas-spec

@@ -1,8 +0,0 @@
-What:           /sys/bus/iio/devices/iio:deviceX/battery_low
-KernelVersion:  4.1.0
-Contact:        linux-iio@vger.kernel.org
-Description:
-                Reading returns either '1' or '0'. '1' means that the
-                battery level supplied to sensor is below 2.25V.
-                This ABI is available for tsys02d, htu21, ms8607
-		This ABI is available for htu21, ms8607

Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935

@@ -1,4 +1,4 @@
-What		/sys/bus/iio/devices/iio:deviceX/in_proximity_input
+What		/sys/bus/iio/devices/iio:deviceX/in_proximity_raw
 Date:		March 2014
 KernelVersion:	3.15
 Contact:	Matt Ranostay <mranostay@gmail.com>

Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs

@@ -9,34 +9,3 @@ Description:
 		automated testing or in situations, where other trigger methods
 		are not applicable. For example no RTC or spare GPIOs.
 		X is the IIO index of the trigger.
-
-What:		/sys/bus/iio/devices/triggerX/name
-KernelVersion:	2.6.39
-Contact:	linux-iio@vger.kernel.org
-Description:
-		The name attribute holds a description string for the current
-		trigger. In order to associate the trigger with an IIO device
-		one should write this name string to
-		/sys/bus/iio/devices/iio:deviceY/trigger/current_trigger.
-
-What:		/sys/bus/iio/devices/iio_sysfs_trigger/add_trigger
-KernelVersion:	2.6.39
-Contact:	linux-iio@vger.kernel.org
-Description:
-		This attribute is provided by the iio-trig-sysfs stand-alone
-		driver and it is used to activate the creation of a new trigger.
-		In order to achieve this, one should write a positive integer
-		into the associated file, which will serve as the id of the
-		trigger. If the trigger with the specified id is already present
-		in the system, an invalid argument message will be returned.
-
-What:		/sys/bus/iio/devices/iio_sysfs_trigger/remove_trigger
-KernelVersion:	2.6.39
-Contact:	linux-iio@vger.kernel.org
-Description:
-		This attribute is used to unregister and delete a previously
-		created trigger from the list of available triggers. In order to
-		achieve this, one should write a positive integer into the
-		associated file, representing the id of the trigger that needs
-		to be removed. If the trigger can't be found, an invalid
-		argument message will be returned to the user.

Documentation/ABI/testing/sysfs-bus-iio-vf610

@@ -1,7 +0,0 @@
-What:		/sys/bus/iio/devices/iio:deviceX/conversion_mode
-KernelVersion:	4.2
-Contact:	linux-iio@vger.kernel.org
-Description:
-		Specifies the hardware conversion mode used. The three
-		available modes are "normal", "high-speed" and "low-power",
-		where the last is the default mode.

Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth

@@ -1,49 +0,0 @@
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/masters/*
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure output ports for STP masters. Writing -1
-		disables a master; any
-
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_port
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RO) Output port type:
-		  0: not present,
-		  1: MSU (Memory Storage Unit)
-		  2: CTP (Common Trace Port)
-		  4: PTI (MIPI PTI).
-
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_drop
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Data retention policy setting: keep (0) or drop (1)
-		incoming data while output port is in reset.
-
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_null
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) STP NULL packet generation: enabled (1) or disabled (0).
-
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_flush
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Force flush data from byte packing buffer for the output
-		port.
-
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_reset
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RO) Output port is in reset (1).
-
-What:		/sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_smcfreq
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) STP sync packet frequency for the port. Specifies the
-		number of clocks between mainenance packets.

Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc

@@ -1,33 +0,0 @@
-What:		/sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/wrap
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure MSC buffer wrapping. 1 == wrapping enabled.
-
-What:		/sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/mode
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure MSC operating mode:
-		  - "single", for contiguous buffer mode (high-order alloc);
-		  - "multi", for multiblock mode;
-		  - "ExI", for DCI handler mode;
-		  - "debug", for debug mode.
-		If operating mode changes, existing buffer is deallocated,
-		provided there are no active users and tracing is not enabled,
-		otherwise the write will fail.
-
-What:		/sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/nr_pages
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure MSC buffer size for "single" or "multi" modes.
-		In single mode, this is a single number of pages, has to be
-		power of 2. In multiblock mode, this is a comma-separated list
-		of numbers of pages for each window to be allocated. Number of
-		windows is not limited.
-		Writing to this file deallocates existing buffer (provided
-		there are no active users and tracing is not enabled) and then
-		allocates a new one.
-
-

Documentation/ABI/testing/sysfs-bus-intel_th-devices-pti

@@ -1,24 +0,0 @@
-What:		/sys/bus/intel_th/devices/<intel_th_id>-pti/mode
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure PTI output width. Currently supported values
-		are 4, 8, 12, 16.
-
-What:		/sys/bus/intel_th/devices/<intel_th_id>-pti/freerunning_clock
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) 0: PTI trace clock acts as a strobe which only toggles
-		when there is trace data to send. 1: PTI trace clock is a
-		free-running clock.
-
-What:		/sys/bus/intel_th/devices/<intel_th_id>-pti/clock_divider
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Configure PTI port clock divider:
-		 - 0: Intel TH clock rate,
-		 - 1: 1/2 Intel TH clock rate,
-		 - 2: 1/4 Intel TH clock rate,
-		 - 3: 1/8 Intel TH clock rate.

Documentation/ABI/testing/sysfs-bus-intel_th-output-devices

@@ -1,13 +0,0 @@
-What:		/sys/bus/intel_th/devices/<intel_th_id>-<device><id>/active
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RW) Writes of 1 or 0 enable or disable trace output to this
-		output device. Reads return current status.
-
-What:		/sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/port
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:	(RO) Port number, corresponding to this output device on the
-		switch (GTH).

Documentation/ABI/testing/sysfs-bus-mei

@@ -4,25 +4,4 @@ KernelVersion:	3.10
 Contact:	Samuel Ortiz <sameo@linux.intel.com>
 		linux-mei@linux.intel.com
 Description:	Stores the same MODALIAS value emitted by uevent
-		Format: mei:<mei device name>:<device uuid>:
-
-What:		/sys/bus/mei/devices/.../name
-Date:		May 2015
-KernelVersion:	4.2
-Contact:	Tomas Winkler <tomas.winkler@intel.com>
-Description:	Stores mei client device name
-		Format: string
-
-What:		/sys/bus/mei/devices/.../uuid
-Date:		May 2015
-KernelVersion:	4.2
-Contact:	Tomas Winkler <tomas.winkler@intel.com>
-Description:	Stores mei client device uuid
-		Format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
-
-What:		/sys/bus/mei/devices/.../version
-Date:		Aug 2015
-KernelVersion:	4.3
-Contact:	Tomas Winkler <tomas.winkler@intel.com>
-Description:	Stores mei client protocol version
-		Format: %d
+		Format: mei:<mei device name>

Documentation/ABI/testing/sysfs-bus-pci-drivers-janz-cmodio

@@ -1,8 +0,0 @@
-What:		/sys/bus/pci/drivers/janz-cmodio/.../modulbus_number
-Date:		May 2010
-KernelVersion:	2.6.35
-Contact:	Ira W. Snyder <ira.snyder@gmail.com>
-Description:
-		Value representing the HEX switch S2 of the janz carrier board CMOD-IO or CAN-PCI2
-
-		Read-only: value of the configuration switch (0..15)

Documentation/ABI/testing/sysfs-bus-usb

@@ -1,23 +1,3 @@
-What:		/sys/bus/usb/devices/INTERFACE/authorized
-Date:		August 2015
-Description:
-		This allows to authorize (1) or deauthorize (0)
-		individual interfaces instead a whole device
-		in contrast to the device authorization.
-		If a deauthorized interface will be authorized
-		so the driver probing must be triggered manually
-		by writing INTERFACE to /sys/bus/usb/drivers_probe
-		This allows to avoid side-effects with drivers
-		that need multiple interfaces.
-		A deauthorized interface cannot be probed or claimed.
-
-What:		/sys/bus/usb/devices/usbX/interface_authorized_default
-Date:		August 2015
-Description:
-		This is used as value that determines if interfaces
-		would be authorized by default.
-		The value can be 1 or 0. It's by default 1.
-
 What:		/sys/bus/usb/device/.../authorized
 Date:		July 2008
 KernelVersion:	2.6.26
@@ -134,22 +114,6 @@ Description:
 		enabled for the device. Developer can write y/Y/1 or n/N/0 to
 		the file to enable/disable the feature.
 
-What:		/sys/bus/usb/devices/.../power/usb3_hardware_lpm_u1
-		/sys/bus/usb/devices/.../power/usb3_hardware_lpm_u2
-Date:		November 2015
-Contact:	Kevin Strasser <kevin.strasser@linux.intel.com>
-		Lu Baolu <baolu.lu@linux.intel.com>
-Description:
-		If CONFIG_PM is set and a USB 3.0 lpm-capable device is plugged
-		in to a xHCI host which supports link PM, it will check if U1
-		and U2 exit latencies have been set in the BOS descriptor; if
-		the check is passed and the host supports USB3 hardware LPM,
-		USB3 hardware LPM will be enabled for the device and the USB
-		device directory will contain two files named
-		power/usb3_hardware_lpm_u1 and power/usb3_hardware_lpm_u2. These
-		files hold a string value (enable or disable) indicating whether
-		or not USB3 hardware LPM U1 or U2 is enabled for the device.
-
 What:		/sys/bus/usb/devices/.../removable
 Date:		February 2012
 Contact:	Matthew Garrett <mjg@redhat.com>

Documentation/ABI/testing/sysfs-bus-usb-lvstest

@@ -4,14 +4,14 @@ driver is bound with root hub device.
 
 What:		/sys/bus/usb/devices/.../get_dev_desc
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Write to this node to issue "Get Device Descriptor"
 		for Link Layer Validation device. It is needed for TD.7.06.
 
 What:		/sys/bus/usb/devices/.../u1_timeout
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Set "U1 timeout" for the downstream port where Link Layer
 		Validation device is connected. Timeout value must be between 0
@@ -19,7 +19,7 @@ Description:
 
 What:		/sys/bus/usb/devices/.../u2_timeout
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Set "U2 timeout" for the downstream port where Link Layer
 		Validation device is connected. Timeout value must be between 0
@@ -27,21 +27,21 @@ Description:
 
 What:		/sys/bus/usb/devices/.../hot_reset
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Write to this node to issue "Reset" for Link Layer Validation
 		device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35.
 
 What:		/sys/bus/usb/devices/.../u3_entry
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Write to this node to issue "U3 entry" for Link Layer
 		Validation device. It is needed for TD.7.35 and TD.7.36.
 
 What:		/sys/bus/usb/devices/.../u3_exit
 Date:		March 2014
-Contact:	Pratyush Anand <pratyush.anand@gmail.com>
+Contact:	Pratyush Anand <pratyush.anand@st.com>
 Description:
 		Write to this node to issue "U3 exit" for Link Layer
 		Validation device. It is needed for TD.7.36.

Documentation/ABI/testing/sysfs-class-cxl

@@ -6,17 +6,6 @@ Example: The real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
 
 Slave contexts (eg. /sys/class/cxl/afu0.0s):
 
-What:           /sys/class/cxl/<afu>/afu_err_buf
-Date:           September 2014
-Contact:        linuxppc-dev@lists.ozlabs.org
-Description:    read only
-                AFU Error Buffer contents. The contents of this file are
-		application specific and depends on the AFU being used.
-		Applications interacting with the AFU can use this attribute
-		to know about the current error condition and take appropriate
-		action like logging the event etc.
-
-
 What:           /sys/class/cxl/<afu>/irqs_max
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
@@ -26,7 +15,6 @@ Description:    read/write
                 that hardware can support (eg. 2037). Write values will limit
                 userspace applications to that many userspace interrupts. Must
                 be >= irqs_min.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<afu>/irqs_min
 Date:           September 2014
@@ -36,7 +24,6 @@ Description:    read only
                 userspace must request on a CXL_START_WORK ioctl. Userspace may
                 omit the num_interrupts field in the START_WORK IOCTL to get
                 this minimum automatically.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<afu>/mmio_size
 Date:           September 2014
@@ -44,7 +31,6 @@ Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Decimal value of the size of the MMIO space that may be mmaped
                 by userspace.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<afu>/modes_supported
 Date:           September 2014
@@ -52,7 +38,6 @@ Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 List of the modes this AFU supports. One per line.
                 Valid entries are: "dedicated_process" and "afu_directed"
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<afu>/mode
 Date:           September 2014
@@ -61,7 +46,6 @@ Description:    read/write
                 The current mode the AFU is using. Will be one of the modes
                 given in modes_supported. Writing will change the mode
                 provided that no user contexts are attached.
-Users:		https://github.com/ibm-capi/libcxl
 
 
 What:           /sys/class/cxl/<afu>/prefault_mode
@@ -75,7 +59,6 @@ Description:    read/write
                                  descriptor as an effective address and
                                  prefault what it points to.
                         all: all segments process calling START_WORK maps.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<afu>/reset
 Date:           September 2014
@@ -83,14 +66,12 @@ Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    write only
                 Writing 1 here will reset the AFU provided there are not
                 contexts active on the AFU.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<afu>/api_version
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Decimal value of the current version of the kernel/user API.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<afu>/api_version_compatible
 Date:           September 2014
@@ -98,7 +79,6 @@ Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Decimal value of the the lowest version of the userspace API
                 this this kernel supports.
-Users:		https://github.com/ibm-capi/libcxl
 
 
 AFU configuration records (eg. /sys/class/cxl/afu0.0/cr0):
@@ -112,7 +92,6 @@ Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
 		Hexadecimal value of the vendor ID found in this AFU
 		configuration record.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<afu>/cr<config num>/device
 Date:           February 2015
@@ -120,15 +99,13 @@ Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
 		Hexadecimal value of the device ID found in this AFU
 		configuration record.
-Users:		https://github.com/ibm-capi/libcxl
 
-What:           /sys/class/cxl/<afu>/cr<config num>/class
+What:           /sys/class/cxl/<afu>/cr<config num>/vendor
 Date:           February 2015
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
 		Hexadecimal value of the class code found in this AFU
 		configuration record.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<afu>/cr<config num>/config
 Date:           February 2015
@@ -138,7 +115,6 @@ Description:    read only
 		record. The format is expected to match the either the standard
 		or extended configuration space defined by the PCIe
 		specification.
-Users:		https://github.com/ibm-capi/libcxl
 
 
 
@@ -150,21 +126,18 @@ Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Decimal value of the size of the MMIO space that may be mmaped
                 by userspace. This includes all slave contexts space also.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<afu>m/pp_mmio_len
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Decimal value of the Per Process MMIO space length.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<afu>m/pp_mmio_off
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Decimal value of the Per Process MMIO space offset.
-Users:		https://github.com/ibm-capi/libcxl
 
 
 Card info (eg. /sys/class/cxl/card0)
@@ -174,14 +147,12 @@ Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Identifies the CAIA Version the card implements.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<card>/psl_revision
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Identifies the revision level of the PSL.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<card>/base_image
 Date:           September 2014
@@ -191,7 +162,6 @@ Description:    read only
                 that support loadable PSLs. For FPGAs this field identifies
                 the image contained in the on-adapter flash which is loaded
                 during the initial program load.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<card>/image_loaded
 Date:           September 2014
@@ -199,7 +169,6 @@ Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                 Will return "user" or "factory" depending on the image loaded
                 onto the card.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<card>/load_image_on_perst
 Date:           December 2014
@@ -214,7 +183,6 @@ Description:    read/write
                 user or factory image to be loaded.
                 Default is to reload on PERST whichever image the card has
                 loaded.
-Users:		https://github.com/ibm-capi/libcxl
 
 What:           /sys/class/cxl/<card>/reset
 Date:           October 2014
@@ -222,14 +190,3 @@ Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    write only
                 Writing 1 will issue a PERST to card which may cause the card
                 to reload the FPGA depending on load_image_on_perst.
-Users:		https://github.com/ibm-capi/libcxl
-
-What:		/sys/class/cxl/<card>/perst_reloads_same_image
-Date:		July 2015
-Contact:	linuxppc-dev@lists.ozlabs.org
-Description:	read/write
-		Trust that when an image is reloaded via PERST, it will not
-		have changed.
-		0 = don't trust, the image may be different (default)
-		1 = trust that the image will not change.
-Users:		https://github.com/ibm-capi/libcxl

Documentation/ABI/testing/sysfs-class-fpga-manager

@@ -1,37 +0,0 @@
-What:		/sys/class/fpga_manager/<fpga>/name
-Date:		August 2015
-KernelVersion:	4.3
-Contact:	Alan Tull <atull@opensource.altera.com>
-Description:	Name of low level fpga manager driver.
-
-What:		/sys/class/fpga_manager/<fpga>/state
-Date:		August 2015
-KernelVersion:	4.3
-Contact:	Alan Tull <atull@opensource.altera.com>
-Description:	Read fpga manager state as a string.
-		The intent is to provide enough detail that if something goes
-		wrong during FPGA programming (something that the driver can't
-		fix) then userspace can know, i.e. if the firmware request
-		fails, that could be due to not being able to find the firmware
-		file.
-
-		This is a superset of FPGA states and fpga manager driver
-		states.  The fpga manager driver is walking through these steps
-		to get the FPGA into a known operating state.  It's a sequence,
-		though some steps may get skipped.  Valid FPGA states will vary
-		by manufacturer; this is a superset.
-
-		* unknown		= can't determine state
-		* power off		= FPGA power is off
-		* power up		= FPGA reports power is up
-		* reset			= FPGA held in reset state
-		* firmware request	= firmware class request in progress
-		* firmware request error = firmware request failed
-		* write init		= preparing FPGA for programming
-		* write init error	= Error while preparing FPGA for
-					  programming
-		* write			= FPGA ready to receive image data
-		* write error		= Error while programming
-		* write complete	= Doing post programming steps
-		* write complete error	= Error while doing post programming
-		* operating		= FPGA is programmed and operating

Documentation/ABI/testing/sysfs-class-led-flash

@@ -1,80 +0,0 @@
-What:		/sys/class/leds/<led>/flash_brightness
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read/write
-		Set the brightness of this LED in the flash strobe mode, in
-		microamperes. The file is created only for the flash LED devices
-		that support setting flash brightness.
-
-		The value is between 0 and
-		/sys/class/leds/<led>/max_flash_brightness.
-
-What:		/sys/class/leds/<led>/max_flash_brightness
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read only
-		Maximum brightness level for this LED in the flash strobe mode,
-		in microamperes.
-
-What:		/sys/class/leds/<led>/flash_timeout
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read/write
-		Hardware timeout for flash, in microseconds. The flash strobe
-		is stopped after this period of time has passed from the start
-		of the strobe. The file is created only for the flash LED
-		devices that support setting flash timeout.
-
-What:		/sys/class/leds/<led>/max_flash_timeout
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read only
-		Maximum flash timeout for this LED, in microseconds.
-
-What:		/sys/class/leds/<led>/flash_strobe
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read/write
-		Flash strobe state. When written with 1 it triggers flash strobe
-		and when written with 0 it turns the flash off.
-
-		On read 1 means that flash is currently strobing and 0 means
-		that flash is off.
-
-What:		/sys/class/leds/<led>/flash_fault
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	Jacek Anaszewski <j.anaszewski@samsung.com>
-Description:	read only
-		Space separated list of flash faults that may have occurred.
-		Flash faults are re-read after strobing the flash. Possible
-		flash faults:
-
-		* led-over-voltage - flash controller voltage to the flash LED
-			has exceeded the limit specific to the flash controller
-		* flash-timeout-exceeded - the flash strobe was still on when
-			the timeout set by the user has expired; not all flash
-			controllers may set this in all such conditions
-		* controller-over-temperature - the flash controller has
-			overheated
-		* controller-short-circuit - the short circuit protection
-			of the flash controller has been triggered
-		* led-power-supply-over-current - current in the LED power
-			supply has exceeded the limit specific to the flash
-			controller
-		* indicator-led-fault - the flash controller has detected
-			a short or open circuit condition on the indicator LED
-		* led-under-voltage - flash controller voltage to the flash
-			LED has been below the minimum limit specific to
-			the flash
-		* controller-under-voltage - the input voltage of the flash
-			controller is below the limit under which strobing the
-			flash at full current will not be possible;
-			the condition persists until this flag is no longer set
-		* led-over-temperature - the temperature of the LED has exceeded
-			its allowed upper limit

Documentation/ABI/testing/sysfs-class-mic.txt

@@ -41,15 +41,18 @@ Description:
 		When read, this entry provides the current state of an Intel
 		MIC device in the context of the card OS. Possible values that
 		will be read are:
-		"ready" - The MIC device is ready to boot the card OS. On
+		"offline" - The MIC device is ready to boot the card OS. On
 		reading this entry after an OSPM resume, a "boot" has to be
 		written to this entry if the card was previously shutdown
 		during OSPM suspend.
-		"booting" - The MIC device has initiated booting a card OS.
-		"online" - The MIC device has completed boot and is online
+		"online" - The MIC device has initiated booting a card OS.
 		"shutting_down" - The card OS is shutting down.
-		"resetting" - A reset has been initiated for the MIC device
 		"reset_failed" - The MIC device has failed to reset.
+		"suspending" - The MIC device is currently being prepared for
+		suspend. On reading this entry, a "suspend" has to be written
+		to the state sysfs entry to ensure the card is shutdown during
+		OSPM suspend.
+		"suspended" - The MIC device has been suspended.
 
 		When written, this sysfs entry triggers different state change
 		operations depending upon the current state of the card OS.
@@ -59,6 +62,8 @@ Description:
 			sysfs entries.
 		"reset" - Initiates device reset.
 		"shutdown" - Initiates card OS shutdown.
+		"suspend" - Initiates card OS shutdown and also marks the card
+		as suspended.
 
 What:		/sys/class/mic/mic(x)/shutdown_status
 Date:		October 2013
@@ -121,7 +126,7 @@ Description:
 		the card. This sysfs entry can be written with the following
 		valid strings:
 		a) linux - Boot a Linux image.
-		b) flash - Boot an image for flash updates.
+		b) elf - Boot an elf image for flash updates.
 
 What:		/sys/class/mic/mic(x)/log_buf_addr
 Date:		October 2013
@@ -150,17 +155,3 @@ Description:
 		daemon to set the log buffer length address. The correct log
 		buffer length address to be written can be found in the
 		System.map file of the card OS.
-
-What:		/sys/class/mic/mic(x)/heartbeat_enable
-Date:		March 2015
-KernelVersion:	3.20
-Contact:	Ashutosh Dixit <ashutosh.dixit@intel.com>
-Description:
-		The MIC drivers detect and inform user space about card crashes
-		via a heartbeat mechanism (see the description of
-		shutdown_status above). User space can turn off this
-		notification by setting heartbeat_enable to 0 and enable it by
-		setting this entry to 1. If this notification is disabled it is
-		the responsibility of user space to detect card crashes via
-		alternative means such as a network ping. This setting is
-		enabled by default.

Documentation/ABI/testing/sysfs-class-mtd

@@ -222,13 +222,3 @@ Description:
 		The number of blocks that are marked as reserved, if any, in
 		this partition. These are typically used to store the in-flash
 		bad block table (BBT).
-
-What:		/sys/class/mtd/mtdX/offset
-Date:		March 2015
-KernelVersion:	4.1
-Contact:	linux-mtd@lists.infradead.org
-Description:
-		For a partition, the offset of that partition from the start
-		of the master device in bytes. This attribute is absent on
-		main devices, so it can be used to distinguish between
-		partitions and devices that aren't partitions.

Documentation/ABI/testing/sysfs-class-net

@@ -39,25 +39,6 @@ Description:
 		Format is a string, e.g: 00:11:22:33:44:55 for an Ethernet MAC
 		address.
 
-What:		/sys/class/net/<bridge iface>/bridge/group_fwd_mask
-Date:		January 2012
-KernelVersion:	3.2
-Contact:	netdev@vger.kernel.org
-Description:
-		Bitmask to allow forwarding of link local frames with address
-		01-80-C2-00-00-0X on a bridge device. Only values that set bits
-		not matching BR_GROUPFWD_RESTRICTED in net/bridge/br_private.h
-		allowed.
-		Default value 0 does not forward any link local frames.
-
-		Restricted bits:
-		0: 01-80-C2-00-00-00 Bridge Group Address used for STP
-		1: 01-80-C2-00-00-01 (MAC Control) 802.3 used for MAC PAUSE
-		2: 01-80-C2-00-00-02 (Link Aggregation) 802.3ad
-
-		Any values not setting these bits can be used. Take special
-		care when forwarding control frames e.g. 802.1X-PAE or LLDP.
-
 What:		/sys/class/net/<iface>/broadcast
 Date:		April 2005
 KernelVersion:	2.6.12
@@ -207,14 +188,6 @@ Description:
 		Indicates the interface unique physical port identifier within
 		the NIC, as a string.
 
-What:		/sys/class/net/<iface>/phys_port_name
-Date:		March 2015
-KernelVersion:	4.0
-Contact:	netdev@vger.kernel.org
-Description:
-		Indicates the interface physical port name within the NIC,
-		as a string.
-
 What:		/sys/class/net/<iface>/speed
 Date:		October 2009
 KernelVersion:	2.6.33

Documentation/ABI/testing/sysfs-class-net-janz-ican3

@@ -1,19 +0,0 @@
-What:		/sys/class/net/<iface>/termination
-Date:		May 2010
-KernelVersion:	2.6.35
-Contact:	Ira W. Snyder <ira.snyder@gmail.com>
-Description:
-		Value representing the can bus termination
-
-		Default: 1 (termination active)
-		Reading: get actual termination state
-		Writing: set actual termination state (0=no termination, 1=termination active)
-
-What:		/sys/class/net/<iface>/fwinfo
-Date:		May 2015
-KernelVersion:	3.19
-Contact:	Andreas Gröger <andreas24groeger@gmail.com>
-Description:
-		Firmware stamp of ican3 module
-		Read-only: 32 byte string identification of the ICAN3 module
-		(known values: "JANZ-ICAN3 ICANOS 1.xx", "JANZ-ICAN3 CAL/CANopen 1.xx")

Documentation/ABI/testing/sysfs-class-net-queues

@@ -24,14 +24,6 @@ Description:
 		Indicates the number of transmit timeout events seen by this
 		network interface transmit queue.
 
-What:		/sys/class/<iface>/queues/tx-<queue>/tx_maxrate
-Date:		March 2015
-KernelVersion:	4.1
-Contact:	netdev@vger.kernel.org
-Description:
-		A Mbps max-rate set for the queue, a value of zero means disabled,
-		default is disabled.
-
 What:		/sys/class/<iface>/queues/tx-<queue>/xps_cpus
 Date:		November 2010
 KernelVersion:	2.6.38

Documentation/ABI/testing/sysfs-class-power

@@ -74,61 +74,3 @@ Description:
 
 		Valid values:
 		- 0 - 70 (minutes), step by 10 (rounded down)
-
-What:		/sys/class/power_supply/bq24257-charger/ovp_voltage
-Date:		October 2015
-KernelVersion:	4.4.0
-Contact:	Andreas Dannenberg <dannenberg@ti.com>
-Description:
-		This entry configures the overvoltage protection feature of bq24257-
-		type charger devices. This feature protects the device and other
-		components against damage from overvoltage on the input supply. See
-		device datasheet for details.
-
-		Valid values:
-		- 6000000, 6500000, 7000000, 8000000, 9000000, 9500000, 10000000,
-		  10500000 (all uV)
-
-What:		/sys/class/power_supply/bq24257-charger/in_dpm_voltage
-Date:		October 2015
-KernelVersion:	4.4.0
-Contact:	Andreas Dannenberg <dannenberg@ti.com>
-Description:
-		This entry configures the input dynamic power path management voltage of
-		bq24257-type charger devices. Once the supply drops to the configured
-		voltage, the input current limit is reduced down to prevent the further
-		drop of the supply. When the IC enters this mode, the charge current is
-		lower than the set value. See device datasheet for details.
-
-		Valid values:
-		- 4200000, 4280000, 4360000, 4440000, 4520000, 4600000, 4680000,
-		  4760000 (all uV)
-
-What:		/sys/class/power_supply/bq24257-charger/high_impedance_enable
-Date:		October 2015
-KernelVersion:	4.4.0
-Contact:	Andreas Dannenberg <dannenberg@ti.com>
-Description:
-		This entry allows enabling the high-impedance mode of bq24257-type
-		charger devices. If enabled, it places the charger IC into low power
-		standby mode with the switch mode controller disabled. When disabled,
-		the charger operates normally. See device datasheet for details.
-
-		Valid values:
-		- 1: enabled
-		- 0: disabled
-
-What:		/sys/class/power_supply/bq24257-charger/sysoff_enable
-Date:		October 2015
-KernelVersion:	4.4.0
-Contact:	Andreas Dannenberg <dannenberg@ti.com>
-Description:
-		This entry allows enabling the sysoff mode of bq24257-type charger
-		devices. If enabled and the input is removed, the internal battery FET
-		is turned off in order to reduce the leakage from the BAT pin to less
-		than 1uA. Note that on some devices/systems this disconnects the battery
-		from the system. See device datasheet for details.
-
-		Valid values:
-		- 1: enabled
-		- 0: disabled

Documentation/ABI/testing/sysfs-class-power-twl4030

@@ -1,45 +0,0 @@
-What: /sys/class/power_supply/twl4030_ac/max_current
-      /sys/class/power_supply/twl4030_usb/max_current
-Description:
-	Read/Write limit on current which may
-	be drawn from the ac (Accessory Charger) or
-	USB port.
-
-	Value is in micro-Amps.
-
-	Value is set automatically to an appropriate
-	value when a cable is plugged or unplugged.
-
-	Value can the set by writing to the attribute.
-	The change will only persist until the next
-	plug event.  These event are reported via udev.
-
-
-What: /sys/class/power_supply/twl4030_usb/mode
-Description:
-	Changing mode for USB port.
-	Writing to this can disable charging.
-
-	Possible values are:
-		"auto" - draw power as appropriate for detected
-			 power source and battery status.
-		"off"  - do not draw any power.
-		"continuous"
-		       - activate mode described as "linear" in
-		         TWL data sheets.  This uses whatever
-			 current is available and doesn't switch off
-			 when voltage drops.
-
-			 This is useful for unstable power sources
-			 such as bicycle dynamo, but care should
-			 be taken that battery is not over-charged.
-
-What: /sys/class/power_supply/twl4030_ac/mode
-Description:
-	Changing mode for 'ac' port.
-	Writing to this can disable charging.
-
-	Possible values are:
-		"auto" - draw power as appropriate for detected
-			 power source and battery status.
-		"off"  - do not draw any power.

Documentation/ABI/testing/sysfs-class-scsi_tape

@@ -1,109 +0,0 @@
-What:           /sys/class/scsi_tape/*/stats/in_flight
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Show the number of I/Os currently in-flight between the st
-		module and the SCSI mid-layer.
-Users:
-
-
-What:           /sys/class/scsi_tape/*/stats/io_ns
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total amount of time spent waiting for all I/O
-                to and from the tape drive to complete. This includes all
-                reads, writes, and other SCSI commands issued to the tape
-                drive. An example of other SCSI commands would be tape
-                movement such as a rewind when a rewind tape device is
-                closed. This item is measured in nanoseconds.
-
-                To determine the amount of time spent waiting for other I/O
-                to complete subtract read_ns and write_ns from this value.
-Users:
-
-
-What:           /sys/class/scsi_tape/*/stats/other_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		The number of I/O requests issued to the tape drive other
-		than SCSI read/write requests.
-Users:
-
-
-What:           /sys/class/scsi_tape/*/stats/read_byte_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total number of bytes requested from the tape drive.
-		This value is presented in bytes because tape drives support
-		variable length block sizes.
-Users:
-
-
-What:           /sys/class/scsi_tape/*/stats/read_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total number of read requests issued to the tape
-		drive.
-Users:
-
-
-What:           /sys/class/scsi_tape/*/stats/read_ns
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total amount of time in nanoseconds waiting for
-		read I/O requests to complete.
-Users:
-
-
-What:           /sys/class/scsi_tape/*/stats/write_byte_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total number of bytes written to the tape drive.
-		This value is presented in bytes because tape drives support
-		variable length block sizes.
-Users:
-
-
-What:           /sys/class/scsi_tape/*/stats/write_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total number of write requests issued to the tape
-		drive.
-Users:
-
-
-What:           /sys/class/scsi_tape/*/stats/write_ms
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the total amount of time in nanoseconds waiting for
-		write I/O requests to complete.
-Users:
-
-
-What:           /sys/class/scsi_tape/*/stats/resid_cnt
-Date:           Apr 2015
-KernelVersion:  4.2
-Contact:        Shane Seymour <shane.seymour@hp.com>
-Description:
-		Shows the number of times we found that a residual >0
-		was found when the SCSI midlayer indicated that there was
-		an error. For reads this may be a case of someone issuing
-		reads greater than the block size.
-Users:

Documentation/ABI/testing/sysfs-class-stm

@@ -1,14 +0,0 @@
-What:		/sys/class/stm/<stm>/masters
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:
-		Shows first and last available to software master numbers on
-		this STM device.
-
-What:		/sys/class/stm/<stm>/channels
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:
-		Shows the number of channels per master on this STM device.

Documentation/ABI/testing/sysfs-class-stm_source

@@ -1,11 +0,0 @@
-What:		/sys/class/stm_source/<stm_source>/stm_source_link
-Date:		June 2015
-KernelVersion:	4.3
-Contact:	Alexander Shishkin <alexander.shishkin@linux.intel.com>
-Description:
-		stm_source device linkage to stm device, where its tracing data
-		is directed. Reads return an existing connection or "<none>" if
-		this stm_source is not connected to any stm device yet.
-		Write an existing (registered) stm device's name here to
-		connect that device. If a device is already connected to this
-		stm_source, it will first be disconnected.

Documentation/ABI/testing/sysfs-class-zram

@@ -1,24 +0,0 @@
-What:		/sys/class/zram-control/
-Date:		August 2015
-KernelVersion:	4.2
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		The zram-control/ class sub-directory belongs to zram
-		device class
-
-What:		/sys/class/zram-control/hot_add
-Date:		August 2015
-KernelVersion:	4.2
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		RO attribute. Read operation will cause zram to add a new
-		device and return its device id back to user (so one can
-		use /dev/zram<id>), or error code.
-
-What:		/sys/class/zram-control/hot_remove
-Date:		August 2015
-KernelVersion:	4.2
-Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
-		WO attribute. Remove a specific /dev/zramX device, where X
-		is a device_id provided by user.

Documentation/ABI/testing/sysfs-devices-system-cpu

@@ -162,7 +162,7 @@ Description:	Discover CPUs in the same CPU frequency coordination domain
 What:		/sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
 Date:		August 2008
 KernelVersion:	2.6.27
-Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Contact:	discuss@x86-64.org
 Description:	Disable L3 cache indices
 
 		These files exist in every CPU's cache/index3 directory. Each
@@ -243,7 +243,7 @@ Description:	Parameters for the CPU cache attributes
 		coherency_line_size: the minimum amount of data in bytes that gets
 				     transferred from memory to cache
 
-		level: the cache hierarchy in the multi-level cache configuration
+		level: the cache hierarcy in the multi-level cache configuration
 
 		number_of_sets: total number of sets in the cache, a set is a
 				collection of cache lines with the same cache index

Documentation/ABI/testing/sysfs-driver-hid

@@ -8,13 +8,3 @@ Description:	When read, this file returns the device's raw binary HID
 		report descriptor.
 		This file cannot be written.
 Users:		HIDAPI library (http://www.signal11.us/oss/hidapi)
-
-What:		For USB devices	: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/country
-		For BT devices	: /sys/class/bluetooth/hci<addr>/<hid-bus>:<vendor-id>:<product-id>.<num>/country
-		Symlink		: /sys/class/hidraw/hidraw<num>/device/country
-Date:		February 2015
-KernelVersion:	3.19
-Contact:	Olivier Gay <ogay@logitech.com>
-Description:	When read, this file returns the hex integer value in ASCII
-		of the device's HID country code (e.g. 21 for US).
-		This file cannot be written.

Documentation/ABI/testing/sysfs-driver-hid-corsair

@@ -1,15 +0,0 @@
-What:		/sys/bus/drivers/corsair/<dev>/macro_mode
-Date:		August 2015
-KernelVersion:	4.2
-Contact:	Clement Vuchener <clement.vuchener@gmail.com>
-Description:	Get/set the current playback mode. "SW" for software mode
-		where G-keys triggers their regular key codes. "HW" for
-		hardware playback mode where the G-keys play their macro
-		from the on-board memory.
-
-
-What:		/sys/bus/drivers/corsair/<dev>/current_profile
-Date:		August 2015
-KernelVersion:	4.2
-Contact:	Clement Vuchener <clement.vuchener@gmail.com>
-Description:	Get/set the current selected profile. Values are from 1 to 3.

Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff

@@ -1,52 +1,7 @@
-What:		/sys/bus/hid/drivers/logitech/<dev>/range
+What:		/sys/module/hid_logitech/drivers/hid:logitech/<dev>/range.
 Date:		July 2011
 KernelVersion:	3.2
-Contact:	Michal Malý <madcatxster@devoid-pointer.net>
+Contact:	Michal Malý <madcatxster@gmail.com>
 Description:	Display minimum, maximum and current range of the steering
 		wheel. Writing a value within min and max boundaries sets the
 		range of the wheel.
-
-What:		/sys/bus/hid/drivers/logitech/<dev>/alternate_modes
-Date:		Feb 2015
-KernelVersion:	4.1
-Contact:	Michal Malý <madcatxster@devoid-pointer.net>
-Description:	Displays a set of alternate modes supported by a wheel. Each
-		mode is listed as follows:
-		  Tag: Mode Name
-		Currently active mode is marked with an asterisk. List also
-		contains an abstract item "native" which always denotes the
-		native mode of the wheel. Echoing the mode tag switches the
-		wheel into the corresponding mode. Depending on the exact model
-		of the wheel not all listed modes might always be selectable.
-		If a wheel cannot be switched into the desired mode, -EINVAL
-		is returned accompanied with an explanatory message in the
-		kernel log.
-		This entry is not created for devices that have only one mode.
-
-		Currently supported mode switches:
-		Driving Force Pro:
-		  DF-EX --> DFP
-
-		G25:
-		  DF-EX --> DFP --> G25
-
-		G27:
-		  DF-EX <*> DFP <-> G25 <-> G27
-		  DF-EX <*--------> G25 <-> G27
-		  DF-EX <*----------------> G27
-
-		DFGT:
-		  DF-EX <*> DFP <-> DFGT
-		  DF-EX <*--------> DFGT
-
-		* hid_logitech module must be loaded with lg4ff_no_autoswitch=1
-		  parameter set in order for the switch to DF-EX mode to work.
-
-What:		/sys/bus/hid/drivers/logitech/<dev>/real_id
-Date:		Feb 2015
-KernelVersion:	4.1
-Contact:	Michal Malý <madcatxster@devoid-pointer.net>
-Description:	Displays the real model of the wheel regardless of any
-		alternate mode the wheel might be switched to.
-		It is a read-only value.
-		This entry is not created for devices that have only one mode.

Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus

@@ -0,0 +1,96 @@
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
+Date:		October 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 actual
+                profile. This value is persistent, so its equivalent to the
+                profile that's active when the mouse is powered on next time.
+		When written, this file sets the number of the startup profile
+		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>/info
+Date:		November 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.
+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
+Date:		October 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The mouse can store a macro with max 500 key/button strokes
+		internally.
+		When written, this file lets one set the sequence for a specific
+		button for a specific profile. Button and profile numbers are
+		included in written data. The data has to be 2082 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>/koneplus/roccatkoneplus<minor>/profile_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 written, this file lets one write the respective profile
+		buttons back to the mouse. The data has to be 77 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile 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>/koneplus/roccatkoneplus<minor>/profile_settings
+Date:		October 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 written, this file lets one write the respective profile
+		settings back to the mouse. The data has to be 43 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile 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>/koneplus/roccatkoneplus<minor>/sensor
+Date:		October 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	The mouse has a tracking- and a distance-control-unit. These
+		can be activated/deactivated and the lift-off distance can be
+		set. The data has to be 6 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>/koneplus/roccatkoneplus<minor>/talk
+Date:		May 2011
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	Used to active some easy* functions of the mouse from outside.
+		The data has to be 16 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>/koneplus/roccatkoneplus<minor>/tcu
+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. Also lets one read/write sensor
+		registers.
+		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
+Date:		October 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	When read the mouse returns a 30x30 pixel image of the
+		sampled underground. This works only in the course of a
+		calibration process initiated with tcu.
+		The returned data is 1028 bytes in size.
+		This file is readonly.
+Users:		http://roccat.sourceforge.net

Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus

@@ -0,0 +1,49 @@
+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>
+Description:	The integer value of this attribute ranges from 0-4.
+		When read, this attribute returns the number of the active
+		profile.
+		When written, the mouse activates this profile immediately.
+		The profile that's active when powered down is the same that's
+		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>/info
+Date:		November 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 6 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>/kovaplus/roccatkovaplus<minor>/profile_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 written, this file lets one write the respective profile
+		buttons back to the mouse. The data has to be 23 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile 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>/kovaplus/roccatkovaplus<minor>/profile_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 written, this file lets one write the respective profile
+		settings back to the mouse. The data has to be 16 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile to read.
+Users:		http://roccat.sourceforge.net

Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra

@@ -0,0 +1,49 @@
+What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/info
+Date:		November 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 6 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>/pyra/roccatpyra<minor>/profile_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 written, this file lets one write the respective profile
+		settings back to the mouse. The data has to be 13 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile 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>/pyra/roccatpyra<minor>/profile_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 written, this file lets one write the respective profile
+		buttons back to the mouse. The data has to be 19 bytes long.
+		The mouse will reject invalid data.
+		Which profile to write is determined by the profile number
+		contained in the data.
+		Before reading this file, control has to be written to select
+		which profile 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>/pyra/roccatpyra<minor>/settings
+Date:		August 2010
+Contact:	Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:	When read, this file returns the settings stored in the mouse.
+		The size of the data is 3 bytes and holds information on the
+		startup_profile.
+		When written, this file lets write settings back to the mouse.
+		The data has to be 3 bytes long. The mouse will reject invalid
+		data.
+Users:		http://roccat.sourceforge.net

Documentation/ABI/testing/sysfs-driver-ppi

@@ -1,4 +1,4 @@
-What:		/sys/class/tpm/tpmX/ppi/
+What:		/sys/devices/pnp0/<bus-num>/ppi/
 Date:		August 2012
 Kernel Version:	3.6
 Contact:	xiaoyan.zhang@intel.com
@@ -8,14 +8,9 @@ Description:
 		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/
 
-		In Linux 4.2 ppi was moved to the character device directory.
-		A symlink from tpmX/device/ppi to tpmX/ppi to provide backwards
-		compatibility.
-
-What:		/sys/class/tpm/tpmX/ppi/version
+What:		/sys/devices/pnp0/<bus-num>/ppi/version
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:
@@ -23,7 +18,7 @@ Description:
 		platform.
 		This file is readonly.
 
-What:		/sys/class/tpm/tpmX/ppi/request
+What:		/sys/devices/pnp0/<bus-num>/ppi/request
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:
@@ -33,7 +28,7 @@ Description:
 		integer value range from 1 to 160, and 0 means no request.
 		This file can be read and written.
 
-What:		/sys/class/tpm/tpmX/ppi/response
+What:		/sys/devices/pnp0/00:<bus-num>/ppi/response
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:
@@ -42,7 +37,7 @@ Description:
 		: <response description>".
 		This file is readonly.
 
-What:		/sys/class/tpm/tpmX/ppi/transition_action
+What:		/sys/devices/pnp0/<bus-num>/ppi/transition_action
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:
@@ -52,7 +47,7 @@ Description:
 		description>".
 		This file is readonly.
 
-What:		/sys/class/tpm/tpmX/ppi/tcg_operations
+What:		/sys/devices/pnp0/<bus-num>/ppi/tcg_operations
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:
@@ -63,7 +58,7 @@ Description:
 		This attribute is only supported by PPI version 1.2+.
 		This file is readonly.
 
-What:		/sys/class/tpm/tpmX/ppi/vs_operations
+What:		/sys/devices/pnp0/<bus-num>/ppi/vs_operations
 Date:		August 2012
 Contact:	xiaoyan.zhang@intel.com
 Description:

Documentation/ABI/testing/sysfs-driver-st

@@ -1,12 +0,0 @@
-What:		/sys/bus/scsi/drivers/st/debug_flag
-Date:		October 2015
-Kernel Version:	?.?
-Contact:	shane.seymour@hpe.com
-Description:
-		This file allows you to turn debug output from the st driver
-		off if you write a '0' to the file or on if you write a '1'.
-		Note that debug output requires that the module be compiled
-		with the #define DEBUG set to a non-zero value (this is the
-		default). If DEBUG is set to 0 then this file will not
-		appear in sysfs as its presence is conditional upon debug
-		output support being compiled into the module.

Documentation/ABI/testing/sysfs-driver-sunxi-sid

@@ -0,0 +1,22 @@
+What:		/sys/devices/*/<our-device>/eeprom
+Date:		August 2013
+Contact:	Oliver Schinagl <oliver@schinagl.nl>
+Description:	read-only access to the SID (Security-ID) on current
+		A-series SoC's from Allwinner. Currently supports A10, A10s, A13
+		and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
+		whereas the newer A20 SoC exposes 512 bytes split into sections.
+		Besides the 16 bytes of SID, there's also an SJTAG area,
+		HDMI-HDCP key and some custom keys. Below a quick overview, for
+		details see the user manual:
+		0x000  128 bit root-key (sun[457]i)
+		0x010  128 bit boot-key (sun7i)
+		0x020   64 bit security-jtag-key (sun7i)
+		0x028   16 bit key configuration (sun7i)
+		0x02b   16 bit custom-vendor-key (sun7i)
+		0x02c  320 bit low general key (sun7i)
+		0x040   32 bit read-control access (sun7i)
+		0x064  224 bit low general key (sun7i)
+		0x080 2304 bit HDCP-key (sun7i)
+		0x1a0  768 bit high general key (sun7i)
+Users:		any user space application which wants to read the SID on
+		Allwinner's A-series of CPU's.

Documentation/ABI/testing/sysfs-driver-toshiba_acpi

@@ -8,11 +8,9 @@ Description:	This file controls the keyboard backlight operation mode, valid
 			* 0x2  -> AUTO (also called TIMER)
 			* 0x8  -> ON
 			* 0x10 -> OFF
-		Note that from kernel 3.16 onwards this file accepts all listed
+		Note that the kernel 3.16 onwards this file accepts all listed
 		parameters, kernel 3.15 only accepts the first two (FN-Z and
 		AUTO).
-		Also note that toggling this value on type 1 devices, requires
-		a reboot for changes to take effect.
 Users:		KToshiba
 
 What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_timeout
@@ -69,72 +67,15 @@ Description:	This file shows the current keyboard backlight type,
 			* 2 -> Type 2, supporting modes TIMER, ON and OFF
 Users:		KToshiba
 
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_charge
-Date:		January 23, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the USB Sleep & Charge charging mode, which
-		can be:
-			* 0 -> Disabled		(0x00)
-			* 1 -> Alternate	(0x09)
-			* 2 -> Auto		(0x21)
-			* 3 -> Typical		(0x11)
-		Note that from kernel 4.1 onwards this file accepts all listed
-		values, kernel 4.0 only supports the first three.
-		Note that this feature only works when connected to power, if
-		you want to use it under battery, see the entry named
-		"sleep_functions_on_battery"
-Users:		KToshiba
-
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/sleep_functions_on_battery
-Date:		January 23, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the USB Sleep Functions under battery, and
-		set the level at which point they will be disabled, accepted
-		values can be:
-			* 0	-> Disabled
-			* 1-100	-> Battery level to disable sleep functions
-		Currently it prints two values, the first one indicates if the
-		feature is enabled or disabled, while the second one shows the
-		current battery level set.
-		Note that when the value is set to disabled, the sleep function
-		will only work when connected to power.
-Users:		KToshiba
-
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_rapid_charge
-Date:		January 23, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the USB Rapid Charge state, which can be:
-			* 0 -> Disabled
-			* 1 -> Enabled
-		Note that toggling this value requires a reboot for changes to
-		take effect.
-Users:		KToshiba
-
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_music
-Date:		January 23, 2015
-KernelVersion:	4.0
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the Sleep & Music state, which values can be:
-			* 0 -> Disabled
-			* 1 -> Enabled
-		Note that this feature only works when connected to power, if
-		you want to use it under battery, see the entry named
-		"sleep_functions_on_battery"
-Users:		KToshiba
-
 What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/version
-Date:		February 12, 2015
-KernelVersion:	4.0
+Date:		February, 2015
+KernelVersion:	3.20
 Contact:	Azael Avalos <coproscefalo@gmail.com>
 Description:	This file shows the current version of the driver
-Users:		KToshiba
 
 What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/fan
-Date:		February 12, 2015
-KernelVersion:	4.0
+Date:		February, 2015
+KernelVersion:	3.20
 Contact:	Azael Avalos <coproscefalo@gmail.com>
 Description:	This file controls the state of the internal fan, valid
 		values are:
@@ -142,8 +83,8 @@ Description:	This file controls the state of the internal fan, valid
 			* 1 -> ON
 
 What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_function_keys
-Date:		February 12, 2015
-KernelVersion:	4.0
+Date:		February, 2015
+KernelVersion:	3.20
 Contact:	Azael Avalos <coproscefalo@gmail.com>
 Description:	This file controls the Special Functions (hotkeys) operation
 		mode, valid values are:
@@ -153,29 +94,21 @@ Description:	This file controls the Special Functions (hotkeys) operation
 		and the hotkeys are accessed via FN-F{1-12}.
 		In the "Special Functions" mode, the F{1-12} keys trigger the
 		hotkey and the F{1-12} keys are accessed via FN-F{1-12}.
-		Note that toggling this value requires a reboot for changes to
-		take effect.
-Users:		KToshiba
 
 What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/panel_power_on
-Date:		February 12, 2015
-KernelVersion:	4.0
+Date:		February, 2015
+KernelVersion:	3.20
 Contact:	Azael Avalos <coproscefalo@gmail.com>
 Description:	This file controls whether the laptop should turn ON whenever
 		the LID is opened, valid values are:
 			* 0 -> Disabled
 			* 1 -> Enabled
-		Note that toggling this value requires a reboot for changes to
-		take effect.
-Users:		KToshiba
 
 What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_three
-Date:		February 12, 2015
-KernelVersion:	4.0
+Date:		February, 2015
+KernelVersion:	3.20
 Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the USB 3 functionality, valid values are:
+Description:	This file controls whether the USB 3 functionality, valid
+		values are:
 			* 0 -> Disabled (Acts as a regular USB 2)
 			* 1 -> Enabled (Full USB 3 functionality)
-		Note that toggling this value requires a reboot for changes to
-		take effect.
-Users:		KToshiba

Documentation/ABI/testing/sysfs-driver-toshiba_haps

@@ -1,20 +0,0 @@
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/protection_level
-Date:		August 16, 2014
-KernelVersion:	3.17
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file controls the built-in accelerometer protection level,
-		valid values are:
-			* 0 -> Disabled
-			* 1 -> Low
-			* 2 -> Medium
-			* 3 -> High
-		The default potection value is set to 2 (Medium).
-Users:		KToshiba
-
-What:		/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/reset_protection
-Date:		August 16, 2014
-KernelVersion:	3.17
-Contact:	Azael Avalos <coproscefalo@gmail.com>
-Description:	This file turns off the built-in accelerometer for a few
-		seconds and then restore normal operation. Accepting 1 as the
-		only parameter.

Documentation/ABI/testing/sysfs-driver-wacom

@@ -77,22 +77,3 @@ Description:
 		The format is also scrambled, like in the USB mode, and it can
 		be summarized by converting 76543210 into GECA6420.
 					    HGFEDCBA      HFDB7531
-
-What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_remote/unpair_remote
-Date:		July 2015
-Contact:	linux-input@vger.kernel.org
-Description:
-		Writing the character sequence '*' followed by a newline to
-		this file will delete all of the current pairings on the
-		device. Other character sequences are reserved. This file is
-		write only.
-
-What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_remote/<serial_number>/remote_mode
-Date:		July 2015
-Contact:	linux-input@vger.kernel.org
-Description:
-		Reading from this file reports the mode status of the
-		remote as indicated by the LED lights on the device. If no
-		reports have been received from the paired device, reading
-		from this file will report '-1'. The mode is read-only
-		and cannot be set through the driver.

Documentation/ABI/testing/sysfs-firmware-dmi

@@ -0,0 +1,110 @@
+What:		/sys/firmware/dmi/
+Date:		February 2011
+Contact:	Mike Waychison <mikew@google.com>
+Description:
+		Many machines' firmware (x86 and ia64) export DMI /
+		SMBIOS tables to the operating system.  Getting at this
+		information is often valuable to userland, especially in
+		cases where there are OEM extensions used.
+
+		The kernel itself does not rely on the majority of the
+		information in these tables being correct.  It equally
+		cannot ensure that the data as exported to userland is
+		without error either.
+
+		DMI is structured as a large table of entries, where
+		each entry has a common header indicating the type and
+		length of the entry, as well as a firmware-provided
+		'handle' that is supposed to be unique amongst all
+		entries.
+
+		Some entries are required by the specification, but many
+		others are optional.  In general though, users should
+		never expect to find a specific entry type on their
+		system unless they know for certain what their firmware
+		is doing.  Machine to machine experiences will vary.
+
+		Multiple entries of the same type are allowed.  In order
+		to handle these duplicate entry types, each entry is
+		assigned by the operating system an 'instance', which is
+		derived from an entry type's ordinal position.  That is
+		to say, if there are 'N' multiple entries with the same type
+		'T' in the DMI tables (adjacent or spread apart, it
+		doesn't matter), they will be represented in sysfs as
+		entries "T-0" through "T-(N-1)":
+
+		Example entry directories:
+
+			/sys/firmware/dmi/entries/17-0
+			/sys/firmware/dmi/entries/17-1
+			/sys/firmware/dmi/entries/17-2
+			/sys/firmware/dmi/entries/17-3
+			...
+
+		Instance numbers are used in lieu of the firmware
+		assigned entry handles as the kernel itself makes no
+		guarantees that handles as exported are unique, and
+		there are likely firmware images that get this wrong in
+		the wild.
+
+		Each DMI entry in sysfs has the common header values
+		exported as attributes:
+
+		handle	: The 16bit 'handle' that is assigned to this
+			  entry by the firmware.  This handle may be
+			  referred to by other entries.
+		length	: The length of the entry, as presented in the
+			  entry itself.  Note that this is _not the
+			  total count of bytes associated with the
+			  entry_.  This value represents the length of
+			  the "formatted" portion of the entry.  This
+			  "formatted" region is sometimes followed by
+			  the "unformatted" region composed of nul
+			  terminated strings, with termination signalled
+			  by a two nul characters in series.
+		raw	: The raw bytes of the entry. This includes the
+			  "formatted" portion of the entry, the
+			  "unformatted" strings portion of the entry,
+			  and the two terminating nul characters.
+		type	: The type of the entry.  This value is the same
+			  as found in the directory name.  It indicates
+			  how the rest of the entry should be interpreted.
+		instance: The instance ordinal of the entry for the
+			  given type.  This value is the same as found
+			  in the parent directory name.
+		position: The ordinal position (zero-based) of the entry
+			  within the entirety of the DMI entry table.
+
+		=== Entry Specialization ===
+
+		Some entry types may have other information available in
+		sysfs.  Not all types are specialized.
+
+		--- Type 15 - System Event Log ---
+
+		This entry allows the firmware to export a log of
+		events the system has taken.  This information is
+		typically backed by nvram, but the implementation
+		details are abstracted by this table.  This entry's data
+		is exported in the directory:
+
+		/sys/firmware/dmi/entries/15-0/system_event_log
+
+		and has the following attributes (documented in the
+		SMBIOS / DMI specification under "System Event Log (Type 15)":
+
+		area_length
+		header_start_offset
+		data_start_offset
+		access_method
+		status
+		change_token
+		access_method_address
+		header_format
+		per_log_type_descriptor_length
+		type_descriptors_supported_count
+
+		As well, the kernel exports the binary attribute:
+
+		raw_event_log	: The raw binary bits of the event log
+				  as described by the DMI entry.

Documentation/ABI/testing/sysfs-firmware-dmi-entries

@@ -1,110 +0,0 @@
-What:		/sys/firmware/dmi/entries/
-Date:		February 2011
-Contact:	Mike Waychison <mikew@google.com>
-Description:
-		Many machines' firmware (x86 and ia64) export DMI /
-		SMBIOS tables to the operating system.  Getting at this
-		information is often valuable to userland, especially in
-		cases where there are OEM extensions used.
-
-		The kernel itself does not rely on the majority of the
-		information in these tables being correct.  It equally
-		cannot ensure that the data as exported to userland is
-		without error either.
-
-		DMI is structured as a large table of entries, where
-		each entry has a common header indicating the type and
-		length of the entry, as well as a firmware-provided
-		'handle' that is supposed to be unique amongst all
-		entries.
-
-		Some entries are required by the specification, but many
-		others are optional.  In general though, users should
-		never expect to find a specific entry type on their
-		system unless they know for certain what their firmware
-		is doing.  Machine to machine experiences will vary.
-
-		Multiple entries of the same type are allowed.  In order
-		to handle these duplicate entry types, each entry is
-		assigned by the operating system an 'instance', which is
-		derived from an entry type's ordinal position.  That is
-		to say, if there are 'N' multiple entries with the same type
-		'T' in the DMI tables (adjacent or spread apart, it
-		doesn't matter), they will be represented in sysfs as
-		entries "T-0" through "T-(N-1)":
-
-		Example entry directories:
-
-			/sys/firmware/dmi/entries/17-0
-			/sys/firmware/dmi/entries/17-1
-			/sys/firmware/dmi/entries/17-2
-			/sys/firmware/dmi/entries/17-3
-			...
-
-		Instance numbers are used in lieu of the firmware
-		assigned entry handles as the kernel itself makes no
-		guarantees that handles as exported are unique, and
-		there are likely firmware images that get this wrong in
-		the wild.
-
-		Each DMI entry in sysfs has the common header values
-		exported as attributes:
-
-		handle	: The 16bit 'handle' that is assigned to this
-			  entry by the firmware.  This handle may be
-			  referred to by other entries.
-		length	: The length of the entry, as presented in the
-			  entry itself.  Note that this is _not the
-			  total count of bytes associated with the
-			  entry_.  This value represents the length of
-			  the "formatted" portion of the entry.  This
-			  "formatted" region is sometimes followed by
-			  the "unformatted" region composed of nul
-			  terminated strings, with termination signalled
-			  by a two nul characters in series.
-		raw	: The raw bytes of the entry. This includes the
-			  "formatted" portion of the entry, the
-			  "unformatted" strings portion of the entry,
-			  and the two terminating nul characters.
-		type	: The type of the entry.  This value is the same
-			  as found in the directory name.  It indicates
-			  how the rest of the entry should be interpreted.
-		instance: The instance ordinal of the entry for the
-			  given type.  This value is the same as found
-			  in the parent directory name.
-		position: The ordinal position (zero-based) of the entry
-			  within the entirety of the DMI entry table.
-
-		=== Entry Specialization ===
-
-		Some entry types may have other information available in
-		sysfs.  Not all types are specialized.
-
-		--- Type 15 - System Event Log ---
-
-		This entry allows the firmware to export a log of
-		events the system has taken.  This information is
-		typically backed by nvram, but the implementation
-		details are abstracted by this table.  This entry's data
-		is exported in the directory:
-
-		/sys/firmware/dmi/entries/15-0/system_event_log
-
-		and has the following attributes (documented in the
-		SMBIOS / DMI specification under "System Event Log (Type 15)":
-
-		area_length
-		header_start_offset
-		data_start_offset
-		access_method
-		status
-		change_token
-		access_method_address
-		header_format
-		per_log_type_descriptor_length
-		type_descriptors_supported_count
-
-		As well, the kernel exports the binary attribute:
-
-		raw_event_log	: The raw binary bits of the event log
-				  as described by the DMI entry.

Documentation/ABI/testing/sysfs-firmware-dmi-tables

@@ -1,22 +0,0 @@
-What:		/sys/firmware/dmi/tables/
-Date:		April 2015
-Contact:	Ivan Khoronzhuk <ivan.khoronzhuk@globallogic.com>
-Description:
-		The firmware provides DMI structures as a packed list of
-		data referenced by a SMBIOS table entry point. The SMBIOS
-		entry point contains general information, like SMBIOS
-		version, DMI table size, etc. The structure, content and
-		size of SMBIOS entry point is dependent on SMBIOS version.
-		The format of SMBIOS entry point and DMI structures
-		can be read in SMBIOS specification.
-
-		The dmi/tables provides raw SMBIOS entry point and DMI tables
-		through sysfs as an alternative to utilities reading them
-		from /dev/mem. The raw SMBIOS entry point and DMI table are
-		presented as binary attributes and are accessible via:
-
-		/sys/firmware/dmi/tables/smbios_entry_point
-		/sys/firmware/dmi/tables/DMI
-
-		The complete DMI information can be obtained using these two
-		tables.

Documentation/ABI/testing/sysfs-firmware-efi

@@ -18,13 +18,3 @@ Contact:	Dave Young <dyoung@redhat.com>
 Description:	It shows the physical address of config table entry in the EFI
 		system table.
 Users:		Kexec
-
-What:		/sys/firmware/efi/systab
-Date:		April 2005
-Contact:	linux-efi@vger.kernel.org
-Description:	Displays the physical addresses of all EFI Configuration
-		Tables found via the EFI System Table. The order in
-		which the tables are printed forms an ABI and newer
-		versions are always printed first, i.e. ACPI20 comes
-		before ACPI.
-Users:		dmidecode

Documentation/ABI/testing/sysfs-firmware-efi-esrt

@@ -1,81 +0,0 @@
-What:		/sys/firmware/efi/esrt/
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	Provides userland access to read the EFI System Resource Table
-		(ESRT), a catalog of firmware for which can be updated with
-		the UEFI UpdateCapsule mechanism described in section 7.5 of
-		the UEFI Standard.
-Users:		fwupdate - https://github.com/rhinstaller/fwupdate
-
-What:		/sys/firmware/efi/esrt/fw_resource_count
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The number of entries in the ESRT
-
-What:		/sys/firmware/efi/esrt/fw_resource_count_max
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The maximum number of entries that /could/ be registered
-		in the allocation the table is currently in.  This is
-		really only useful to the system firmware itself.
-
-What:		/sys/firmware/efi/esrt/fw_resource_version
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The version of the ESRT structure provided by the firmware.
-
-What:		/sys/firmware/efi/esrt/entries/entry$N/
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	Each ESRT entry is identified by a GUID, and each gets a
-		subdirectory under entries/ .
-		example: /sys/firmware/efi/esrt/entries/entry0/
-
-What:		/sys/firmware/efi/esrt/entries/entry$N/fw_type
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	What kind of firmware entry this is:
-		0 - Unknown
-		1 - System Firmware
-		2 - Device Firmware
-		3 - UEFI Driver
-
-What:		/sys/firmware/efi/esrt/entries/entry$N/fw_class
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	This is the entry's guid, and will match the directory name.
-
-What:		/sys/firmware/efi/esrt/entries/entry$N/fw_version
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The version of the firmware currently installed.  This is a
-		32-bit unsigned integer.
-
-What:		/sys/firmware/efi/esrt/entries/entry$N/lowest_supported_fw_version
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The lowest version of the firmware that can be installed.
-
-What:		/sys/firmware/efi/esrt/entries/entry$N/capsule_flags
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	Flags that must be passed to UpdateCapsule()
-
-What:		/sys/firmware/efi/esrt/entries/entry$N/last_attempt_version
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The last firmware version for which an update was attempted.
-
-What:		/sys/firmware/efi/esrt/entries/entry$N/last_attempt_status
-Date:		February 2015
-Contact:	Peter Jones <pjones@redhat.com>
-Description:	The result of the last firmware update attempt for the
-		firmware resource entry.
-		0 - Success
-		1 - Insufficient resources
-		2 - Incorrect version
-		3 - Invalid format
-		4 - Authentication error
-		5 - AC power event
-		6 - Battery power event
-

Documentation/ABI/testing/sysfs-fs-f2fs

@@ -80,15 +80,3 @@ Date:		February 2015
 Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
 Description:
 		 Controls the trimming rate in batch mode.
-
-What:		/sys/fs/f2fs/<disk>/cp_interval
-Date:		October 2015
-Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
-Description:
-		 Controls the checkpoint timing.
-
-What:		/sys/fs/f2fs/<disk>/ra_nid_pages
-Date:		October 2015
-Contact:	"Chao Yu" <chao2.yu@samsung.com>
-Description:
-		 Controls the count of nid pages to be readaheaded.

Documentation/ABI/testing/sysfs-gpio

@@ -16,8 +16,7 @@ Description:
     /sys/class/gpio
 	/export ... asks the kernel to export a GPIO to userspace
 	/unexport ... to return a GPIO to the kernel
-	/gpioN ... for each exported GPIO #N OR
-	/<LINE-NAME> ... for a properly named GPIO line
+	/gpioN ... for each exported GPIO #N
 	    /value ... always readable, writes fail for input GPIOs
 	    /direction ... r/w as: in, out (default low); write: high, low
 	    /edge ... r/w as: none, falling, rising, both

Documentation/ABI/testing/sysfs-hypervisor-pmu

@@ -1,23 +0,0 @@
-What:		/sys/hypervisor/pmu/pmu_mode
-Date:		August 2015
-KernelVersion:	4.3
-Contact:	Boris Ostrovsky <boris.ostrovsky@oracle.com>
-Description:
-		Describes mode that Xen's performance-monitoring unit (PMU)
-		uses. Accepted values are
-			"off"  -- PMU is disabled
-			"self" -- The guest can profile itself
-			"hv"   -- The guest can profile itself and, if it is
-				  privileged (e.g. dom0), the hypervisor
-			"all" --  The guest can profile itself, the hypervisor
-				  and all other guests. Only available to
-				  privileged guests.
-
-What:           /sys/hypervisor/pmu/pmu_features
-Date:           August 2015
-KernelVersion:  4.3
-Contact:        Boris Ostrovsky <boris.ostrovsky@oracle.com>
-Description:
-		Describes Xen PMU features (as an integer). A set bit indicates
-		that the corresponding feature is enabled. See
-		include/xen/interface/xenpmu.h for available features

Documentation/ABI/testing/sysfs-platform-dell-laptop

@@ -1,69 +0,0 @@
-What:		/sys/class/leds/dell::kbd_backlight/als_enabled
-Date:		December 2014
-KernelVersion:	3.19
-Contact:	Gabriele Mazzotta <gabriele.mzt@gmail.com>,
-		Pali Rohár <pali.rohar@gmail.com>
-Description:
-		This file allows to control the automatic keyboard
-		illumination mode on some systems that have an ambient
-		light sensor. Write 1 to this file to enable the auto
-		mode, 0 to disable it.
-
-What:		/sys/class/leds/dell::kbd_backlight/als_setting
-Date:		December 2014
-KernelVersion:	3.19
-Contact:	Gabriele Mazzotta <gabriele.mzt@gmail.com>,
-		Pali Rohár <pali.rohar@gmail.com>
-Description:
-		This file allows to specifiy the on/off threshold value,
-		as reported by the ambient light sensor.
-
-What:		/sys/class/leds/dell::kbd_backlight/start_triggers
-Date:		December 2014
-KernelVersion:	3.19
-Contact:	Gabriele Mazzotta <gabriele.mzt@gmail.com>,
-		Pali Rohár <pali.rohar@gmail.com>
-Description:
-		This file allows to control the input triggers that
-		turn on the keyboard backlight illumination that is
-		disabled because of inactivity.
-		Read the file to see the triggers available. The ones
-		enabled are preceded by '+', those disabled by '-'.
-
-		To enable a trigger, write its name preceded by '+' to
-		this file. To disable a trigger, write its name preceded
-		by '-' instead.
-
-		For example, to enable the keyboard as trigger run:
-		    echo +keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
-		To disable it:
-		    echo -keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
-
-		Note that not all the available triggers can be configured.
-
-What:		/sys/class/leds/dell::kbd_backlight/stop_timeout
-Date:		December 2014
-KernelVersion:	3.19
-Contact:	Gabriele Mazzotta <gabriele.mzt@gmail.com>,
-		Pali Rohár <pali.rohar@gmail.com>
-Description:
-		This file allows to specify the interval after which the
-		keyboard illumination is disabled because of inactivity.
-		The timeouts are expressed in seconds, minutes, hours and
-		days, for which the symbols are 's', 'm', 'h' and 'd'
-		respectively.
-
-		To configure the timeout, write to this file a value along
-		with any the above units. If no unit is specified, the value
-		is assumed to be expressed in seconds.
-
-		For example, to set the timeout to 10 minutes run:
-		    echo 10m > /sys/class/leds/dell::kbd_backlight/stop_timeout
-
-		Note that when this file is read, the returned value might be
-		expressed in a different unit than the one used when the timeout
-		was set.
-
-		Also note that only some timeouts are supported and that
-		some systems might fall back to a specific timeout in case
-		an invalid timeout is written to this file.

Documentation/ABI/testing/sysfs-platform-twl4030-usb

@@ -1,8 +0,0 @@
-What: /sys/bus/platform/devices/*twl4030-usb/vbus
-Description:
-	Read-only status reporting if VBUS (approx 5V)
-	is being supplied by the USB bus.
-
-	Possible values: "on", "off".
-
-	Changes are notified via select/poll.

Documentation/ABI/testing/sysfs-power

@@ -256,15 +256,3 @@ Description:
 		Writing a "1" enables this printing while writing a "0"
 		disables it.  The default value is "0".  Reading from this file
 		will display the current value.
-
-What:		/sys/power/pm_wakeup_irq
-Date:		April 2015
-Contact:	Alexandra Yates <alexandra.yates@linux.intel.org>
-Description:
-		The /sys/power/pm_wakeup_irq file reports to user space the IRQ
-		number of the first wakeup interrupt (that is, the first
-		interrupt from an IRQ line armed for system wakeup) seen by the
-		kernel during the most recent system suspend/resume cycle.
-
-		This output is useful for system wakeup diagnostics of spurious
-		wakeup interrupts.

Documentation/Changes

@@ -43,8 +43,6 @@ o  udev                   081                     # udevd --version
 o  grub                   0.93                    # grub --version || grub-install --version
 o  mcelog                 0.6                     # mcelog --version
 o  iptables               1.4.2                   # iptables -V
-o  openssl & libcrypto    1.0.0                   # openssl version
-o  bc                     1.06.95                 # bc --version
 
 
 Kernel compilation
@@ -81,17 +79,6 @@ BC
 You will need bc to build kernels 3.10 and higher
 
 
-OpenSSL
--------
-
-Module signing and external certificate handling use the OpenSSL program and
-crypto library to do key creation and signature generation.
-
-You will need openssl to build kernels 3.7 and higher if module signing is
-enabled.  You will also need openssl development packages to build kernels 4.3
-and higher.
-
-
 System utilities
 ================
 
@@ -308,10 +295,6 @@ Binutils
 --------
 o  <ftp://ftp.kernel.org/pub/linux/devel/binutils/>
 
-OpenSSL
--------
-o  <https://www.openssl.org/>
-
 System utilities
 ****************
 
@@ -409,3 +392,4 @@ o  <http://oprofile.sf.net/download/>
 NFS-Utils
 ---------
 o  <http://nfs.sourceforge.net/>
+

Documentation/CodingStyle

@@ -13,7 +13,7 @@ and NOT read it.  Burn them, it's a great symbolic gesture.
 Anyway, here goes:
 
 
-		Chapter 1: Indentation
+	 	Chapter 1: Indentation
 
 Tabs are 8 characters, and thus indentations are also 8 characters.
 There are heretic movements that try to make indentations 4 (or even 2!)
@@ -56,6 +56,7 @@ instead of "double-indenting" the "case" labels.  E.g.:
 		break;
 	}
 
+
 Don't put multiple statements on a single line unless you have
 something to hide:
 
@@ -155,25 +156,25 @@ comments on.
 
 Do not unnecessarily use braces where a single statement will do.
 
-	if (condition)
-		action();
+if (condition)
+	action();
 
 and
 
-	if (condition)
-		do_this();
-	else
-		do_that();
+if (condition)
+	do_this();
+else
+	do_that();
 
 This does not apply if only one branch of a conditional statement is a single
 statement; in the latter case use braces in both branches:
 
-	if (condition) {
-		do_this();
-		do_that();
-	} else {
-		otherwise();
-	}
+if (condition) {
+	do_this();
+	do_that();
+} else {
+	otherwise();
+}
 
 		3.1:  Spaces
 
@@ -185,11 +186,8 @@ although they are not required in the language, as in: "sizeof info" after
 "struct fileinfo info;" is declared).
 
 So use a space after these keywords:
-
 	if, switch, case, for, do, while
-
 but not with sizeof, typeof, alignof, or __attribute__.  E.g.,
-
 	s = sizeof(struct file);
 
 Do not add spaces around (inside) parenthesized expressions.  This example is
@@ -211,15 +209,12 @@ such as any of these:
 	=  +  -  <  >  *  /  %  |  &  ^  <=  >=  ==  !=  ?  :
 
 but no space after unary operators:
-
 	&  *  +  -  ~  !  sizeof  typeof  alignof  __attribute__  defined
 
 no space before the postfix increment & decrement unary operators:
-
 	++  --
 
 no space after the prefix increment & decrement unary operators:
-
 	++  --
 
 and no space around the '.' and "->" structure member operators.
@@ -273,11 +268,13 @@ See chapter 6 (Functions).
 		Chapter 5: Typedefs
 
 Please don't use things like "vps_t".
+
 It's a _mistake_ to use typedef for structures and pointers. When you see a
 
 	vps_t a;
 
 in the source, what does it mean?
+
 In contrast, if it says
 
 	struct virtual_container *a;
@@ -375,11 +372,11 @@ In source files, separate functions with one blank line.  If the function is
 exported, the EXPORT* macro for it should follow immediately after the closing
 function brace line.  E.g.:
 
-	int system_is_up(void)
-	{
-		return system_state == SYSTEM_RUNNING;
-	}
-	EXPORT_SYMBOL(system_is_up);
+int system_is_up(void)
+{
+	return system_state == SYSTEM_RUNNING;
+}
+EXPORT_SYMBOL(system_is_up);
 
 In function prototypes, include parameter names with their data types.
 Although this is not required by the C language, it is preferred in Linux
@@ -408,34 +405,34 @@ The rationale for using gotos is:
     modifications are prevented
 - saves the compiler work to optimize redundant code away ;)
 
-	int fun(int a)
-	{
-		int result = 0;
-		char *buffer;
+int fun(int a)
+{
+	int result = 0;
+	char *buffer;
 
-		buffer = kmalloc(SIZE, GFP_KERNEL);
-		if (!buffer)
-			return -ENOMEM;
+	buffer = kmalloc(SIZE, GFP_KERNEL);
+	if (!buffer)
+		return -ENOMEM;
 
-		if (condition1) {
-			while (loop1) {
-				...
-			}
-			result = 1;
-			goto out_buffer;
+	if (condition1) {
+		while (loop1) {
+			...
 		}
-		...
-	out_buffer:
-		kfree(buffer);
-		return result;
+		result = 1;
+		goto out_buffer;
 	}
+	...
+out_buffer:
+	kfree(buffer);
+	return result;
+}
 
 A common type of bug to be aware of it "one err bugs" which look like this:
 
-	err:
-		kfree(foo->bar);
-		kfree(foo);
-		return ret;
+err:
+	kfree(foo->bar);
+	kfree(foo);
+	return ret;
 
 The bug in this code is that on some exit paths "foo" is NULL.  Normally the
 fix for this is to split it up into two error labels "err_bar:" and "err_foo:".
@@ -506,9 +503,9 @@ values.  To do the latter, you can stick the following in your .emacs file:
 (defun c-lineup-arglist-tabs-only (ignored)
   "Line up argument lists by tabs, not spaces"
   (let* ((anchor (c-langelem-pos c-syntactic-element))
-         (column (c-langelem-2nd-pos c-syntactic-element))
-         (offset (- (1+ column) anchor))
-         (steps (floor offset c-basic-offset)))
+	 (column (c-langelem-2nd-pos c-syntactic-element))
+	 (offset (- (1+ column) anchor))
+	 (steps (floor offset c-basic-offset)))
     (* (max steps 1)
        c-basic-offset)))
 
@@ -615,7 +612,7 @@ have a reference count on it, you almost certainly have a bug.
 
 Names of macros defining constants and labels in enums are capitalized.
 
-	#define CONSTANT 0x12345
+#define CONSTANT 0x12345
 
 Enums are preferred when defining several related constants.
 
@@ -626,28 +623,28 @@ Generally, inline functions are preferable to macros resembling functions.
 
 Macros with multiple statements should be enclosed in a do - while block:
 
-	#define macrofun(a, b, c) 			\
-		do {					\
-			if (a == 5)			\
-				do_this(b, c);		\
-		} while (0)
+#define macrofun(a, b, c) 			\
+	do {					\
+		if (a == 5)			\
+			do_this(b, c);		\
+	} while (0)
 
 Things to avoid when using macros:
 
 1) macros that affect control flow:
 
-	#define FOO(x)					\
-		do {					\
-			if (blah(x) < 0)		\
-				return -EBUGGERED;	\
-		} while(0)
+#define FOO(x)					\
+	do {					\
+		if (blah(x) < 0)		\
+			return -EBUGGERED;	\
+	} while(0)
 
 is a _very_ bad idea.  It looks like a function call but exits the "calling"
 function; don't break the internal parsers of those who will read the code.
 
 2) macros that depend on having a local variable with a magic name:
 
-	#define FOO(val) bar(index, val)
+#define FOO(val) bar(index, val)
 
 might look like a good thing, but it's confusing as hell when one reads the
 code and it's prone to breakage from seemingly innocent changes.
@@ -659,21 +656,8 @@ bite you if somebody e.g. turns FOO into an inline function.
 must enclose the expression in parentheses. Beware of similar issues with
 macros using parameters.
 
-	#define CONSTANT 0x4000
-	#define CONSTEXP (CONSTANT | 3)
-
-5) namespace collisions when defining local variables in macros resembling
-functions:
-
-#define FOO(x)				\
-({					\
-	typeof(x) ret;			\
-	ret = calc_ret(x);		\
-	(ret);				\
-})
-
-ret is a common name for a local variable - __foo_ret is less likely
-to collide with an existing variable.
+#define CONSTANT 0x4000
+#define CONSTEXP (CONSTANT | 3)
 
 The cpp manual deals with macros exhaustively. The gcc internals manual also
 covers RTL which is used frequently with assembly language in the kernel.
@@ -812,11 +796,11 @@ you should use, rather than explicitly coding some variant of them yourself.
 For example, if you need to calculate the length of an array, take advantage
 of the macro
 
-	#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+  #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
 Similarly, if you need to calculate the size of some structure member, use
 
-	#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
+  #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
 
 There are also min() and max() macros that do strict type checking if you
 need them.  Feel free to peruse that header file to see what else is already
@@ -829,19 +813,19 @@ Some editors can interpret configuration information embedded in source files,
 indicated with special markers.  For example, emacs interprets lines marked
 like this:
 
-	-*- mode: c -*-
+-*- mode: c -*-
 
 Or like this:
 
-	/*
-	Local Variables:
-	compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
-	End:
-	*/
+/*
+Local Variables:
+compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
+End:
+*/
 
 Vim interprets markers that look like this:
 
-	/* vim:set sw=8 noet */
+/* vim:set sw=8 noet */
 
 Do not include any of these in source files.  People have their own personal
 editor configurations, and your source files should not override them.  This
@@ -918,9 +902,9 @@ At the end of any non-trivial #if or #ifdef block (more than a few lines),
 place a comment after the #endif on the same line, noting the conditional
 expression used.  For instance:
 
-	#ifdef CONFIG_SOMETHING
-	...
-	#endif /* CONFIG_SOMETHING */
+#ifdef CONFIG_SOMETHING
+...
+#endif /* CONFIG_SOMETHING */
 
 
 		Appendix I: References
@@ -929,11 +913,13 @@ The C Programming Language, Second Edition
 by Brian W. Kernighan and Dennis M. Ritchie.
 Prentice Hall, Inc., 1988.
 ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
+URL: http://cm.bell-labs.com/cm/cs/cbook/
 
 The Practice of Programming
 by Brian W. Kernighan and Rob Pike.
 Addison-Wesley, Inc., 1999.
 ISBN 0-201-61586-X.
+URL: http://cm.bell-labs.com/cm/cs/tpop/
 
 GNU manuals - where in compliance with K&R and this text - for cpp, gcc,
 gcc internals and indent, all available from http://www.gnu.org/manual/

Documentation/DMA-API-HOWTO.txt

@@ -25,18 +25,13 @@ physical addresses.  These are the addresses in /proc/iomem.  The physical
 address is not directly useful to a driver; it must use ioremap() to map
 the space and produce a virtual address.
 
-I/O devices use a third kind of address: a "bus address".  If a device has
-registers at an MMIO address, or if it performs DMA to read or write system
-memory, the addresses used by the device are bus addresses.  In some
-systems, bus addresses are identical to CPU physical addresses, but in
-general they are not.  IOMMUs and host bridges can produce arbitrary
+I/O devices use a third kind of address: a "bus address" or "DMA address".
+If a device has registers at an MMIO address, or if it performs DMA to read
+or write system memory, the addresses used by the device are bus addresses.
+In some systems, bus addresses are identical to CPU physical addresses, but
+in general they are not.  IOMMUs and host bridges can produce arbitrary
 mappings between physical and bus addresses.
 
-From a device's point of view, DMA uses the bus address space, but it may
-be restricted to a subset of that space.  For example, even if a system
-supports 64-bit addresses for main memory and PCI BARs, it may use an IOMMU
-so devices only need to use 32-bit DMA addresses.
-
 Here's a picture and some examples:
 
                CPU                  CPU                  Bus
@@ -77,11 +72,11 @@ can use virtual address X to access the buffer, but the device itself
 cannot because DMA doesn't go through the CPU virtual memory system.
 
 In some simple systems, the device can do DMA directly to physical address
-Y.  But in many others, there is IOMMU hardware that translates DMA
+Y.  But in many others, there is IOMMU hardware that translates bus
 addresses to physical addresses, e.g., it translates Z to Y.  This is part
 of the reason for the DMA API: the driver can give a virtual address X to
 an interface like dma_map_single(), which sets up any required IOMMU
-mapping and returns the DMA address Z.  The driver then tells the device to
+mapping and returns the bus address Z.  The driver then tells the device to
 do DMA to Z, and the IOMMU maps it to the buffer at address Y in system
 RAM.
 
@@ -103,7 +98,7 @@ First of all, you should make sure
 #include <linux/dma-mapping.h>
 
 is in your driver, which provides the definition of dma_addr_t.  This type
-can hold any valid DMA address for the platform and should be used
+can hold any valid DMA or bus address for the platform and should be used
 everywhere you hold a DMA address returned from the DMA mapping functions.
 
 			 What memory is DMA'able?
@@ -245,7 +240,7 @@ the case would look like this:
 
 	if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
 		using_dac = 1;
-		consistent_using_dac = 1;
+	   	consistent_using_dac = 1;
 	} else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
 		using_dac = 0;
 		consistent_using_dac = 0;
@@ -321,7 +316,7 @@ There are two types of DMA mappings:
   Think of "consistent" as "synchronous" or "coherent".
 
   The current default is to return consistent memory in the low 32
-  bits of the DMA space.  However, for future compatibility you should
+  bits of the bus space.  However, for future compatibility you should
   set the consistent mask even if this default is fine for your
   driver.
 
@@ -358,7 +353,7 @@ There are two types of DMA mappings:
   transfer, unmapped right after it (unless you use dma_sync_* below)
   and for which hardware can optimize for sequential accesses.
 
-  Think of "streaming" as "asynchronous" or "outside the coherency
+  This of "streaming" as "asynchronous" or "outside the coherency
   domain".
 
   Good examples of what to use streaming mappings for are:
@@ -408,7 +403,7 @@ dma_alloc_coherent() returns two values: the virtual address which you
 can use to access it from the CPU and dma_handle which you pass to the
 card.
 
-The CPU virtual address and the DMA address are both
+The CPU virtual address and the DMA bus address are both
 guaranteed to be aligned to the smallest PAGE_SIZE order which
 is greater than or equal to the requested size.  This invariant
 exists (for example) to guarantee that if you allocate a chunk
@@ -650,8 +645,8 @@ PLEASE NOTE:  The 'nents' argument to the dma_unmap_sg call must be
               dma_map_sg call.
 
 Every dma_map_{single,sg}() call should have its dma_unmap_{single,sg}()
-counterpart, because the DMA address space is a shared resource and
-you could render the machine unusable by consuming all DMA addresses.
+counterpart, because the bus address space is a shared resource and
+you could render the machine unusable by consuming all bus addresses.
 
 If you need to use the same streaming DMA region multiple times and touch
 the data in between the DMA transfers, the buffer needs to be synced
@@ -681,11 +676,6 @@ or:
 
 as appropriate.
 
-PLEASE NOTE:  The 'nents' argument to dma_sync_sg_for_cpu() and
-	      dma_sync_sg_for_device() must be the same passed to
-	      dma_map_sg(). It is _NOT_ the count returned by
-	      dma_map_sg().
-
 After the last DMA transfer call one of the DMA unmap routines
 dma_unmap_{single,sg}(). If you don't touch the data from the first
 dma_map_*() call till dma_unmap_*(), then you don't have to call the

Documentation/DMA-API.txt

@@ -18,10 +18,10 @@ Part I - dma_ API
 To get the dma_ API, you must #include <linux/dma-mapping.h>.  This
 provides dma_addr_t and the interfaces described below.
 
-A dma_addr_t can hold any valid DMA address for the platform.  It can be
-given to a device to use as a DMA source or target.  A CPU cannot reference
-a dma_addr_t directly because there may be translation between its physical
-address space and the DMA address space.
+A dma_addr_t can hold any valid DMA or bus address for the platform.  It
+can be given to a device to use as a DMA source or target.  A CPU cannot
+reference a dma_addr_t directly because there may be translation between
+its physical address space and the bus address space.
 
 Part Ia - Using large DMA-coherent buffers
 ------------------------------------------
@@ -42,7 +42,7 @@ It returns a pointer to the allocated region (in the processor's virtual
 address space) or NULL if the allocation failed.
 
 It also returns a <dma_handle> which may be cast to an unsigned integer the
-same width as the bus and given to the device as the DMA address base of
+same width as the bus and given to the device as the bus address base of
 the region.
 
 Note: consistent memory can be expensive on some platforms, and the
@@ -104,13 +104,6 @@ crossing restrictions, pass 0 for alloc; passing 4096 says memory allocated
 from this pool must not cross 4KByte boundaries.
 
 
-	void *dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags,
-			      dma_addr_t *handle)
-
-Wraps dma_pool_alloc() and also zeroes the returned memory if the
-allocation attempt succeeded.
-
-
 	void *dma_pool_alloc(struct dma_pool *pool, gfp_t gfp_flags,
 			dma_addr_t *dma_handle);
 
@@ -141,6 +134,19 @@ memory back to the pool before you destroy it.
 Part Ic - DMA addressing limitations
 ------------------------------------
 
+int
+dma_supported(struct device *dev, u64 mask)
+
+Checks to see if the device can support DMA to the memory described by
+mask.
+
+Returns: 1 if it can and 0 if it can't.
+
+Notes: This routine merely tests to see if the mask is possible.  It
+won't change the current mask settings.  It is more intended as an
+internal API for use by the platform than an external API for use by
+driver writers.
+
 int
 dma_set_mask_and_coherent(struct device *dev, u64 mask)
 
@@ -187,7 +193,7 @@ dma_map_single(struct device *dev, void *cpu_addr, size_t size,
 		      enum dma_data_direction direction)
 
 Maps a piece of processor virtual memory so it can be accessed by the
-device and returns the DMA address of the memory.
+device and returns the bus address of the memory.
 
 The direction for both APIs may be converted freely by casting.
 However the dma_ API uses a strongly typed enumerator for its
@@ -206,20 +212,20 @@ contiguous piece of memory.  For this reason, memory to be mapped by
 this API should be obtained from sources which guarantee it to be
 physically contiguous (like kmalloc).
 
-Further, the DMA address of the memory must be within the
+Further, the bus address of the memory must be within the
 dma_mask of the device (the dma_mask is a bit mask of the
-addressable region for the device, i.e., if the DMA address of
-the memory ANDed with the dma_mask is still equal to the DMA
+addressable region for the device, i.e., if the bus address of
+the memory ANDed with the dma_mask is still equal to the bus
 address, then the device can perform DMA to the memory).  To
 ensure that the memory allocated by kmalloc is within the dma_mask,
 the driver may specify various platform-dependent flags to restrict
-the DMA address range of the allocation (e.g., on x86, GFP_DMA
-guarantees to be within the first 16MB of available DMA addresses,
+the bus address range of the allocation (e.g., on x86, GFP_DMA
+guarantees to be within the first 16MB of available bus addresses,
 as required by ISA devices).
 
 Note also that the above constraints on physical contiguity and
 dma_mask may not apply if the platform has an IOMMU (a device which
-maps an I/O DMA address to a physical memory address).  However, to be
+maps an I/O bus address to a physical memory address).  However, to be
 portable, device driver writers may *not* assume that such an IOMMU
 exists.
 
@@ -290,7 +296,7 @@ reduce current DMA mapping usage or delay and try again later).
 	dma_map_sg(struct device *dev, struct scatterlist *sg,
 		int nents, enum dma_data_direction direction)
 
-Returns: the number of DMA address segments mapped (this may be shorter
+Returns: the number of bus address segments mapped (this may be shorter
 than <nents> passed in if some elements of the scatter/gather list are
 physically or virtually adjacent and an IOMMU maps them with a single
 entry).
@@ -327,14 +333,14 @@ accessed sg->address and sg->length as shown above.
 
 	void
 	dma_unmap_sg(struct device *dev, struct scatterlist *sg,
-		int nents, enum dma_data_direction direction)
+		int nhwentries, enum dma_data_direction direction)
 
 Unmap the previously mapped scatter/gather list.  All the parameters
 must be the same as those and passed in to the scatter/gather mapping
 API.
 
 Note: <nents> must be the number you passed in, *not* the number of
-DMA address entries returned.
+bus address entries returned.
 
 void
 dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size,
@@ -343,10 +349,10 @@ void
 dma_sync_single_for_device(struct device *dev, dma_addr_t dma_handle, size_t size,
 			   enum dma_data_direction direction)
 void
-dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nents,
+dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nelems,
 		    enum dma_data_direction direction)
 void
-dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nents,
+dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems,
 		       enum dma_data_direction direction)
 
 Synchronise a single contiguous or scatter/gather mapping for the CPU
@@ -501,7 +507,7 @@ it's asked for coherent memory for this device.
 phys_addr is the CPU physical address to which the memory is currently
 assigned (this will be ioremapped so the CPU can access the region).
 
-device_addr is the DMA address the device needs to be programmed
+device_addr is the bus address the device needs to be programmed
 with to actually address this memory (this will be handed out as the
 dma_addr_t in dma_alloc_coherent()).
 

Documentation/DocBook/.gitignore

@@ -11,7 +11,5 @@
 *.png
 *.gif
 *.svg
-*.proc
-*.db
 media-indices.tmpl
 media-entities.tmpl

Documentation/DocBook/80211.tmpl

@@ -154,9 +154,8 @@
 !Finclude/net/cfg80211.h cfg80211_scan_request
 !Finclude/net/cfg80211.h cfg80211_scan_done
 !Finclude/net/cfg80211.h cfg80211_bss
-!Finclude/net/cfg80211.h cfg80211_inform_bss
-!Finclude/net/cfg80211.h cfg80211_inform_bss_frame_data
-!Finclude/net/cfg80211.h cfg80211_inform_bss_data
+!Finclude/net/cfg80211.h cfg80211_inform_bss_width_frame
+!Finclude/net/cfg80211.h cfg80211_inform_bss_width
 !Finclude/net/cfg80211.h cfg80211_unlink_bss
 !Finclude/net/cfg80211.h cfg80211_find_ie
 !Finclude/net/cfg80211.h ieee80211_bss_get_ie

Documentation/DocBook/Makefile

@@ -14,8 +14,8 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
 	    genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
 	    80211.xml debugobjects.xml sh.xml regulator.xml \
 	    alsa-driver-api.xml writing-an-alsa-driver.xml \
-	    tracepoint.xml gpu.xml media_api.xml w1.xml \
-	    writing_musb_glue_layer.xml crypto-API.xml iio.xml
+	    tracepoint.xml drm.xml media_api.xml w1.xml \
+	    writing_musb_glue_layer.xml crypto-API.xml
 
 include Documentation/DocBook/media/Makefile
 
@@ -56,25 +56,16 @@ htmldocs: $(HTML)
 
 MAN := $(patsubst %.xml, %.9, $(BOOKS))
 mandocs: $(MAN)
-	find $(obj)/man -name '*.9' | xargs gzip -nf
+	find $(obj)/man -name '*.9' | xargs gzip -f
 
 installmandocs: mandocs
 	mkdir -p /usr/local/man/man9/
-	find $(obj)/man -name '*.9.gz' -printf '%h %f\n' | \
-		sort -k 2 -k 1 | uniq -f 1 | sed -e 's: :/:' | \
-		xargs install -m 644 -t /usr/local/man/man9/
+	install $(obj)/man/*.9.gz /usr/local/man/man9/
 
 ###
 #External programs used
-KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref
-KERNELDOC       = $(srctree)/scripts/kernel-doc
-DOCPROC         = $(objtree)/scripts/docproc
-CHECK_LC_CTYPE = $(objtree)/scripts/check-lc_ctype
-
-# Use a fixed encoding - UTF-8 if the C library has support built-in
-# or ASCII if not
-LC_CTYPE := $(call try-run, LC_CTYPE=C.UTF-8 $(CHECK_LC_CTYPE),C.UTF-8,C)
-export LC_CTYPE
+KERNELDOC = $(srctree)/scripts/kernel-doc
+DOCPROC   = $(objtree)/scripts/docproc
 
 XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
 XMLTOFLAGS += --skip-validation
@@ -98,7 +89,7 @@ define rule_docproc
         ) > $(dir $@).$(notdir $@).cmd
 endef
 
-%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
+%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE
 	$(call if_changed_rule,docproc)
 
 # Tell kbuild to always build the programs
@@ -149,20 +140,7 @@ quiet_cmd_db2html = HTML    $@
 		echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
 		$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
 
-###
-# Rules to create an aux XML and .db, and use them to re-process the DocBook XML
-# to fill internal hyperlinks
-       gen_aux_xml = :
- quiet_gen_aux_xml = echo '  XMLREF  $@'
-silent_gen_aux_xml = :
-%.aux.xml: %.xml
-	@$($(quiet)gen_aux_xml)
-	@rm -rf $@
-	@(cat $< | egrep "^<refentry id" | egrep -o "\".*\"" | cut -f 2 -d \" > $<.db)
-	@$(KERNELDOCXMLREF) -db $<.db $< > $@
-.PRECIOUS: %.aux.xml
-
-%.html:	%.aux.xml
+%.html:	%.xml
 	@(which xmlto > /dev/null 2>&1) || \
 	 (echo "*** You need to install xmlto ***"; \
 	  exit 1)
@@ -172,12 +150,12 @@ silent_gen_aux_xml = :
             cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
 
 quiet_cmd_db2man = MAN     $@
-      cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man/$(*F) $< ; fi
+      cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; fi
 %.9 : %.xml
 	@(which xmlto > /dev/null 2>&1) || \
 	 (echo "*** You need to install xmlto ***"; \
 	  exit 1)
-	$(Q)mkdir -p $(obj)/man/$(*F)
+	$(Q)mkdir -p $(obj)/man
 	$(call cmd,db2man)
 	@touch $@
 
@@ -231,18 +209,15 @@ dochelp:
 ###
 # Temporary files left by various tools
 clean-files := $(DOCBOOKS) \
-	$(patsubst %.xml, %.dvi,     $(DOCBOOKS)) \
-	$(patsubst %.xml, %.aux,     $(DOCBOOKS)) \
-	$(patsubst %.xml, %.tex,     $(DOCBOOKS)) \
-	$(patsubst %.xml, %.log,     $(DOCBOOKS)) \
-	$(patsubst %.xml, %.out,     $(DOCBOOKS)) \
-	$(patsubst %.xml, %.ps,      $(DOCBOOKS)) \
-	$(patsubst %.xml, %.pdf,     $(DOCBOOKS)) \
-	$(patsubst %.xml, %.html,    $(DOCBOOKS)) \
-	$(patsubst %.xml, %.9,       $(DOCBOOKS)) \
-	$(patsubst %.xml, %.aux.xml, $(DOCBOOKS)) \
-	$(patsubst %.xml, %.xml.db,  $(DOCBOOKS)) \
-	$(patsubst %.xml, %.xml,     $(DOCBOOKS)) \
+	$(patsubst %.xml, %.dvi,  $(DOCBOOKS)) \
+	$(patsubst %.xml, %.aux,  $(DOCBOOKS)) \
+	$(patsubst %.xml, %.tex,  $(DOCBOOKS)) \
+	$(patsubst %.xml, %.log,  $(DOCBOOKS)) \
+	$(patsubst %.xml, %.out,  $(DOCBOOKS)) \
+	$(patsubst %.xml, %.ps,   $(DOCBOOKS)) \
+	$(patsubst %.xml, %.pdf,  $(DOCBOOKS)) \
+	$(patsubst %.xml, %.html, $(DOCBOOKS)) \
+	$(patsubst %.xml, %.9,    $(DOCBOOKS)) \
 	$(index)
 
 clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man

Documentation/DocBook/alsa-driver-api.tmpl

@@ -108,12 +108,10 @@
      <sect1><title>ASoC Core API</title>
 !Iinclude/sound/soc.h
 !Esound/soc/soc-core.c
-<!-- !Esound/soc/soc-cache.c no docbook comments here -->
+!Esound/soc/soc-cache.c
 !Esound/soc/soc-devres.c
 !Esound/soc/soc-io.c
 !Esound/soc/soc-pcm.c
-!Esound/soc/soc-ops.c
-!Esound/soc/soc-compress.c
      </sect1>
      <sect1><title>ASoC DAPM API</title>
 !Esound/soc/soc-dapm.c

Documentation/DocBook/crypto-API.tmpl

@@ -119,7 +119,7 @@
 
     <para>
      Note: The terms "transformation" and cipher algorithm are used
-     interchangeably.
+     interchangably.
     </para>
    </sect1>
 
@@ -509,270 +509,6 @@
      select it due to the used type and mask field.
     </para>
    </sect1>
-
-   <sect1><title>Internal Structure of Kernel Crypto API</title>
-
-    <para>
-     The kernel crypto API has an internal structure where a cipher
-     implementation may use many layers and indirections. This section
-     shall help to clarify how the kernel crypto API uses
-     various components to implement the complete cipher.
-    </para>
-
-    <para>
-     The following subsections explain the internal structure based
-     on existing cipher implementations. The first section addresses
-     the most complex scenario where all other scenarios form a logical
-     subset.
-    </para>
-
-    <sect2><title>Generic AEAD Cipher Structure</title>
-
-     <para>
-      The following ASCII art decomposes the kernel crypto API layers
-      when using the AEAD cipher with the automated IV generation. The
-      shown example is used by the IPSEC layer.
-     </para>
-
-     <para>
-      For other use cases of AEAD ciphers, the ASCII art applies as
-      well, but the caller may not use the AEAD cipher with a separate
-      IV generator. In this case, the caller must generate the IV.
-     </para>
-
-     <para>
-      The depicted example decomposes the AEAD cipher of GCM(AES) based
-      on the generic C implementations (gcm.c, aes-generic.c, ctr.c,
-      ghash-generic.c, seqiv.c). The generic implementation serves as an
-      example showing the complete logic of the kernel crypto API.
-     </para>
-
-     <para>
-      It is possible that some streamlined cipher implementations (like
-      AES-NI) provide implementations merging aspects which in the view
-      of the kernel crypto API cannot be decomposed into layers any more.
-      In case of the AES-NI implementation, the CTR mode, the GHASH
-      implementation and the AES cipher are all merged into one cipher
-      implementation registered with the kernel crypto API. In this case,
-      the concept described by the following ASCII art applies too. However,
-      the decomposition of GCM into the individual sub-components
-      by the kernel crypto API is not done any more.
-     </para>
-
-     <para>
-      Each block in the following ASCII art is an independent cipher
-      instance obtained from the kernel crypto API. Each block
-      is accessed by the caller or by other blocks using the API functions
-      defined by the kernel crypto API for the cipher implementation type.
-     </para>
-
-     <para>
-      The blocks below indicate the cipher type as well as the specific
-      logic implemented in the cipher.
-     </para>
-
-     <para>
-      The ASCII art picture also indicates the call structure, i.e. who
-      calls which component. The arrows point to the invoked block
-      where the caller uses the API applicable to the cipher type
-      specified for the block.
-     </para>
-
-     <programlisting>
-<![CDATA[
-kernel crypto API                                |   IPSEC Layer
-                                                 |
-+-----------+                                    |
-|           |            (1)
-|   aead    | <-----------------------------------  esp_output
-|  (seqiv)  | ---+
-+-----------+    |
-                 | (2)
-+-----------+    |
-|           | <--+                (2)
-|   aead    | <-----------------------------------  esp_input
-|   (gcm)   | ------------+
-+-----------+             |
-      | (3)               | (5)
-      v                   v
-+-----------+       +-----------+
-|           |       |           |
-| ablkcipher|       |   ahash   |
-|   (ctr)   | ---+  |  (ghash)  |
-+-----------+    |  +-----------+
-                 |
-+-----------+    | (4)
-|           | <--+
-|   cipher  |
-|   (aes)   |
-+-----------+
-]]>
-     </programlisting>
-
-     <para>
-      The following call sequence is applicable when the IPSEC layer
-      triggers an encryption operation with the esp_output function. During
-      configuration, the administrator set up the use of rfc4106(gcm(aes)) as
-      the cipher for ESP. The following call sequence is now depicted in the
-      ASCII art above:
-     </para>
-
-     <orderedlist>
-      <listitem>
-       <para>
-        esp_output() invokes crypto_aead_encrypt() to trigger an encryption
-        operation of the AEAD cipher with IV generator.
-       </para>
-
-       <para>
-        In case of GCM, the SEQIV implementation is registered as GIVCIPHER
-        in crypto_rfc4106_alloc().
-       </para>
-
-       <para>
-        The SEQIV performs its operation to generate an IV where the core
-        function is seqiv_geniv().
-       </para>
-      </listitem>
-
-      <listitem>
-       <para>
-        Now, SEQIV uses the AEAD API function calls to invoke the associated
-        AEAD cipher. In our case, during the instantiation of SEQIV, the
-        cipher handle for GCM is provided to SEQIV. This means that SEQIV
-        invokes AEAD cipher operations with the GCM cipher handle.
-       </para>
-
-       <para>
-        During instantiation of the GCM handle, the CTR(AES) and GHASH
-        ciphers are instantiated. The cipher handles for CTR(AES) and GHASH
-        are retained for later use.
-       </para>
-
-       <para>
-        The GCM implementation is responsible to invoke the CTR mode AES and
-        the GHASH cipher in the right manner to implement the GCM
-        specification.
-       </para>
-      </listitem>
-
-      <listitem>
-       <para>
-        The GCM AEAD cipher type implementation now invokes the ABLKCIPHER API
-        with the instantiated CTR(AES) cipher handle.
-       </para>
-
-       <para>
-	During instantiation of the CTR(AES) cipher, the CIPHER type
-	implementation of AES is instantiated. The cipher handle for AES is
-	retained.
-       </para>
-
-       <para>
-        That means that the ABLKCIPHER implementation of CTR(AES) only
-        implements the CTR block chaining mode. After performing the block
-        chaining operation, the CIPHER implementation of AES is invoked.
-       </para>
-      </listitem>
-
-      <listitem>
-       <para>
-        The ABLKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
-        cipher handle to encrypt one block.
-       </para>
-      </listitem>
-
-      <listitem>
-       <para>
-        The GCM AEAD implementation also invokes the GHASH cipher
-        implementation via the AHASH API.
-       </para>
-      </listitem>
-     </orderedlist>
-
-     <para>
-      When the IPSEC layer triggers the esp_input() function, the same call
-      sequence is followed with the only difference that the operation starts
-      with step (2).
-     </para>
-    </sect2>
-
-    <sect2><title>Generic Block Cipher Structure</title>
-     <para>
-      Generic block ciphers follow the same concept as depicted with the ASCII
-      art picture above.
-     </para>
-
-     <para>
-      For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The
-      ASCII art picture above applies as well with the difference that only
-      step (4) is used and the ABLKCIPHER block chaining mode is CBC.
-     </para>
-    </sect2>
-
-    <sect2><title>Generic Keyed Message Digest Structure</title>
-     <para>
-      Keyed message digest implementations again follow the same concept as
-      depicted in the ASCII art picture above.
-     </para>
-
-     <para>
-      For example, HMAC(SHA256) is implemented with hmac.c and
-      sha256_generic.c. The following ASCII art illustrates the
-      implementation:
-     </para>
-
-     <programlisting>
-<![CDATA[
-kernel crypto API            |       Caller
-                             |
-+-----------+         (1)    |
-|           | <------------------  some_function
-|   ahash   |
-|   (hmac)  | ---+
-+-----------+    |
-                 | (2)
-+-----------+    |
-|           | <--+
-|   shash   |
-|  (sha256) |
-+-----------+
-]]>
-     </programlisting>
-
-     <para>
-      The following call sequence is applicable when a caller triggers
-      an HMAC operation:
-     </para>
-
-     <orderedlist>
-      <listitem>
-       <para>
-        The AHASH API functions are invoked by the caller. The HMAC
-        implementation performs its operation as needed.
-       </para>
-
-       <para>
-        During initialization of the HMAC cipher, the SHASH cipher type of
-        SHA256 is instantiated. The cipher handle for the SHA256 instance is
-        retained.
-       </para>
-
-       <para>
-        At one time, the HMAC implementation requires a SHA256 operation
-        where the SHA256 cipher handle is used.
-       </para>
-      </listitem>
-
-      <listitem>
-       <para>
-        The HMAC instance now invokes the SHASH API with the SHA256
-        cipher handle to calculate the message digest.
-       </para>
-      </listitem>
-     </orderedlist>
-    </sect2>
-   </sect1>
   </chapter>
 
   <chapter id="Development"><title>Developing Cipher Algorithms</title>
@@ -1072,625 +808,19 @@ kernel crypto API            |       Caller
    </sect1>
   </chapter>
 
-  <chapter id="User"><title>User Space Interface</title>
-   <sect1><title>Introduction</title>
-    <para>
-     The concepts of the kernel crypto API visible to kernel space is fully
-     applicable to the user space interface as well. Therefore, the kernel
-     crypto API high level discussion for the in-kernel use cases applies
-     here as well.
-    </para>
-
-    <para>
-     The major difference, however, is that user space can only act as a
-     consumer and never as a provider of a transformation or cipher algorithm.
-    </para>
-
-    <para>
-     The following covers the user space interface exported by the kernel
-     crypto API. A working example of this description is libkcapi that
-     can be obtained from [1]. That library can be used by user space
-     applications that require cryptographic services from the kernel.
-    </para>
-
-    <para>
-     Some details of the in-kernel kernel crypto API aspects do not
-     apply to user space, however. This includes the difference between
-     synchronous and asynchronous invocations. The user space API call
-     is fully synchronous.
-    </para>
-
-    <para>
-     [1] <ulink url="http://www.chronox.de/libkcapi.html">http://www.chronox.de/libkcapi.html</ulink>
-    </para>
-
-   </sect1>
-
-   <sect1><title>User Space API General Remarks</title>
-    <para>
-     The kernel crypto API is accessible from user space. Currently,
-     the following ciphers are accessible:
-    </para>
-
-    <itemizedlist>
-     <listitem>
-      <para>Message digest including keyed message digest (HMAC, CMAC)</para>
-     </listitem>
-
-     <listitem>
-      <para>Symmetric ciphers</para>
-     </listitem>
-
-     <listitem>
-      <para>AEAD ciphers</para>
-     </listitem>
-
-     <listitem>
-      <para>Random Number Generators</para>
-     </listitem>
-    </itemizedlist>
-
-    <para>
-     The interface is provided via socket type using the type AF_ALG.
-     In addition, the setsockopt option type is SOL_ALG. In case the
-     user space header files do not export these flags yet, use the
-     following macros:
-    </para>
-
-    <programlisting>
-#ifndef AF_ALG
-#define AF_ALG 38
-#endif
-#ifndef SOL_ALG
-#define SOL_ALG 279
-#endif
-    </programlisting>
-
-    <para>
-     A cipher is accessed with the same name as done for the in-kernel
-     API calls. This includes the generic vs. unique naming schema for
-     ciphers as well as the enforcement of priorities for generic names.
-    </para>
-
-    <para>
-     To interact with the kernel crypto API, a socket must be
-     created by the user space application. User space invokes the cipher
-     operation with the send()/write() system call family. The result of the
-     cipher operation is obtained with the read()/recv() system call family.
-    </para>
-
-    <para>
-     The following API calls assume that the socket descriptor
-     is already opened by the user space application and discusses only
-     the kernel crypto API specific invocations.
-    </para>
-
-    <para>
-     To initialize the socket interface, the following sequence has to
-     be performed by the consumer:
-    </para>
-
-    <orderedlist>
-     <listitem>
-      <para>
-       Create a socket of type AF_ALG with the struct sockaddr_alg
-       parameter specified below for the different cipher types.
-      </para>
-     </listitem>
-
-     <listitem>
-      <para>
-       Invoke bind with the socket descriptor
-      </para>
-     </listitem>
-
-     <listitem>
-      <para>
-       Invoke accept with the socket descriptor. The accept system call
-       returns a new file descriptor that is to be used to interact with
-       the particular cipher instance. When invoking send/write or recv/read
-       system calls to send data to the kernel or obtain data from the
-       kernel, the file descriptor returned by accept must be used.
-      </para>
-     </listitem>
-    </orderedlist>
-   </sect1>
-
-   <sect1><title>In-place Cipher operation</title>
-    <para>
-     Just like the in-kernel operation of the kernel crypto API, the user
-     space interface allows the cipher operation in-place. That means that
-     the input buffer used for the send/write system call and the output
-     buffer used by the read/recv system call may be one and the same.
-     This is of particular interest for symmetric cipher operations where a
-     copying of the output data to its final destination can be avoided.
-    </para>
-
-    <para>
-     If a consumer on the other hand wants to maintain the plaintext and
-     the ciphertext in different memory locations, all a consumer needs
-     to do is to provide different memory pointers for the encryption and
-     decryption operation.
-    </para>
-   </sect1>
-
-   <sect1><title>Message Digest API</title>
-    <para>
-     The message digest type to be used for the cipher operation is
-     selected when invoking the bind syscall. bind requires the caller
-     to provide a filled struct sockaddr data structure. This data
-     structure must be filled as follows:
-    </para>
-
-    <programlisting>
-struct sockaddr_alg sa = {
-	.salg_family = AF_ALG,
-	.salg_type = "hash", /* this selects the hash logic in the kernel */
-	.salg_name = "sha1" /* this is the cipher name */
-};
-    </programlisting>
-
-    <para>
-     The salg_type value "hash" applies to message digests and keyed
-     message digests. Though, a keyed message digest is referenced by
-     the appropriate salg_name. Please see below for the setsockopt
-     interface that explains how the key can be set for a keyed message
-     digest.
-    </para>
-
-    <para>
-     Using the send() system call, the application provides the data that
-     should be processed with the message digest. The send system call
-     allows the following flags to be specified:
-    </para>
-
-    <itemizedlist>
-     <listitem>
-      <para>
-       MSG_MORE: If this flag is set, the send system call acts like a
-       message digest update function where the final hash is not
-       yet calculated. If the flag is not set, the send system call
-       calculates the final message digest immediately.
-      </para>
-     </listitem>
-    </itemizedlist>
-
-    <para>
-     With the recv() system call, the application can read the message
-     digest from the kernel crypto API. If the buffer is too small for the
-     message digest, the flag MSG_TRUNC is set by the kernel.
-    </para>
-
-    <para>
-     In order to set a message digest key, the calling application must use
-     the setsockopt() option of ALG_SET_KEY. If the key is not set the HMAC
-     operation is performed without the initial HMAC state change caused by
-     the key.
-    </para>
-   </sect1>
-
-   <sect1><title>Symmetric Cipher API</title>
-    <para>
-     The operation is very similar to the message digest discussion.
-     During initialization, the struct sockaddr data structure must be
-     filled as follows:
-    </para>
-
-    <programlisting>
-struct sockaddr_alg sa = {
-	.salg_family = AF_ALG,
-	.salg_type = "skcipher", /* this selects the symmetric cipher */
-	.salg_name = "cbc(aes)" /* this is the cipher name */
-};
-    </programlisting>
-
-    <para>
-     Before data can be sent to the kernel using the write/send system
-     call family, the consumer must set the key. The key setting is
-     described with the setsockopt invocation below.
-    </para>
-
-    <para>
-     Using the sendmsg() system call, the application provides the data that should be processed for encryption or decryption. In addition, the IV is
-     specified with the data structure provided by the sendmsg() system call.
-    </para>
-
-    <para>
-     The sendmsg system call parameter of struct msghdr is embedded into the
-     struct cmsghdr data structure. See recv(2) and cmsg(3) for more
-     information on how the cmsghdr data structure is used together with the
-     send/recv system call family. That cmsghdr data structure holds the
-     following information specified with a separate header instances:
-    </para>
-
-    <itemizedlist>
-     <listitem>
-      <para>
-       specification of the cipher operation type with one of these flags:
-      </para>
-      <itemizedlist>
-       <listitem>
-        <para>ALG_OP_ENCRYPT - encryption of data</para>
-       </listitem>
-       <listitem>
-        <para>ALG_OP_DECRYPT - decryption of data</para>
-       </listitem>
-      </itemizedlist>
-     </listitem>
-
-     <listitem>
-      <para>
-       specification of the IV information marked with the flag ALG_SET_IV
-      </para>
-     </listitem>
-    </itemizedlist>
-
-    <para>
-     The send system call family allows the following flag to be specified:
-    </para>
-
-    <itemizedlist>
-     <listitem>
-      <para>
-       MSG_MORE: If this flag is set, the send system call acts like a
-       cipher update function where more input data is expected
-       with a subsequent invocation of the send system call.
-      </para>
-     </listitem>
-    </itemizedlist>
-
-    <para>
-     Note: The kernel reports -EINVAL for any unexpected data. The caller
-     must make sure that all data matches the constraints given in
-     /proc/crypto for the selected cipher.
-    </para>
-
-    <para>
-     With the recv() system call, the application can read the result of
-     the cipher operation from the kernel crypto API. The output buffer
-     must be at least as large as to hold all blocks of the encrypted or
-     decrypted data. If the output data size is smaller, only as many
-     blocks are returned that fit into that output buffer size.
-    </para>
-   </sect1>
-
-   <sect1><title>AEAD Cipher API</title>
-    <para>
-     The operation is very similar to the symmetric cipher discussion.
-     During initialization, the struct sockaddr data structure must be
-     filled as follows:
-    </para>
-
-    <programlisting>
-struct sockaddr_alg sa = {
-	.salg_family = AF_ALG,
-	.salg_type = "aead", /* this selects the symmetric cipher */
-	.salg_name = "gcm(aes)" /* this is the cipher name */
-};
-    </programlisting>
-
-    <para>
-     Before data can be sent to the kernel using the write/send system
-     call family, the consumer must set the key. The key setting is
-     described with the setsockopt invocation below.
-    </para>
-
-    <para>
-     In addition, before data can be sent to the kernel using the
-     write/send system call family, the consumer must set the authentication
-     tag size. To set the authentication tag size, the caller must use the
-     setsockopt invocation described below.
-    </para>
-
-    <para>
-     Using the sendmsg() system call, the application provides the data that should be processed for encryption or decryption. In addition, the IV is
-     specified with the data structure provided by the sendmsg() system call.
-    </para>
-
-    <para>
-     The sendmsg system call parameter of struct msghdr is embedded into the
-     struct cmsghdr data structure. See recv(2) and cmsg(3) for more
-     information on how the cmsghdr data structure is used together with the
-     send/recv system call family. That cmsghdr data structure holds the
-     following information specified with a separate header instances:
-    </para>
-
-    <itemizedlist>
-     <listitem>
-      <para>
-       specification of the cipher operation type with one of these flags:
-      </para>
-      <itemizedlist>
-       <listitem>
-        <para>ALG_OP_ENCRYPT - encryption of data</para>
-       </listitem>
-       <listitem>
-        <para>ALG_OP_DECRYPT - decryption of data</para>
-       </listitem>
-      </itemizedlist>
-     </listitem>
-
-     <listitem>
-      <para>
-       specification of the IV information marked with the flag ALG_SET_IV
-      </para>
-     </listitem>
-
-     <listitem>
-      <para>
-       specification of the associated authentication data (AAD) with the
-       flag ALG_SET_AEAD_ASSOCLEN. The AAD is sent to the kernel together
-       with the plaintext / ciphertext. See below for the memory structure.
-      </para>
-     </listitem>
-    </itemizedlist>
-
-    <para>
-     The send system call family allows the following flag to be specified:
-    </para>
-
-    <itemizedlist>
-     <listitem>
-      <para>
-       MSG_MORE: If this flag is set, the send system call acts like a
-       cipher update function where more input data is expected
-       with a subsequent invocation of the send system call.
-      </para>
-     </listitem>
-    </itemizedlist>
-
-    <para>
-     Note: The kernel reports -EINVAL for any unexpected data. The caller
-     must make sure that all data matches the constraints given in
-     /proc/crypto for the selected cipher.
-    </para>
-
-    <para>
-     With the recv() system call, the application can read the result of
-     the cipher operation from the kernel crypto API. The output buffer
-     must be at least as large as defined with the memory structure below.
-     If the output data size is smaller, the cipher operation is not performed.
-    </para>
-
-    <para>
-     The authenticated decryption operation may indicate an integrity error.
-     Such breach in integrity is marked with the -EBADMSG error code.
-    </para>
-
-    <sect2><title>AEAD Memory Structure</title>
-     <para>
-      The AEAD cipher operates with the following information that
-      is communicated between user and kernel space as one data stream:
-     </para>
-
-     <itemizedlist>
-      <listitem>
-       <para>plaintext or ciphertext</para>
-      </listitem>
-
-      <listitem>
-       <para>associated authentication data (AAD)</para>
-      </listitem>
-
-      <listitem>
-       <para>authentication tag</para>
-      </listitem>
-     </itemizedlist>
-
-     <para>
-      The sizes of the AAD and the authentication tag are provided with
-      the sendmsg and setsockopt calls (see there). As the kernel knows
-      the size of the entire data stream, the kernel is now able to
-      calculate the right offsets of the data components in the data
-      stream.
-     </para>
-
-     <para>
-      The user space caller must arrange the aforementioned information
-      in the following order:
-     </para>
-
-     <itemizedlist>
-      <listitem>
-       <para>
-        AEAD encryption input: AAD || plaintext
-       </para>
-      </listitem>
-
-      <listitem>
-       <para>
-        AEAD decryption input: AAD || ciphertext || authentication tag
-       </para>
-      </listitem>
-     </itemizedlist>
-
-     <para>
-      The output buffer the user space caller provides must be at least as
-      large to hold the following data:
-     </para>
-
-     <itemizedlist>
-      <listitem>
-       <para>
-        AEAD encryption output: ciphertext || authentication tag
-       </para>
-      </listitem>
-
-      <listitem>
-       <para>
-        AEAD decryption output: plaintext
-       </para>
-      </listitem>
-     </itemizedlist>
-    </sect2>
-   </sect1>
-
-   <sect1><title>Random Number Generator API</title>
-    <para>
-     Again, the operation is very similar to the other APIs.
-     During initialization, the struct sockaddr data structure must be
-     filled as follows:
-    </para>
-
-    <programlisting>
-struct sockaddr_alg sa = {
-	.salg_family = AF_ALG,
-	.salg_type = "rng", /* this selects the symmetric cipher */
-	.salg_name = "drbg_nopr_sha256" /* this is the cipher name */
-};
-    </programlisting>
-
-    <para>
-     Depending on the RNG type, the RNG must be seeded. The seed is provided
-     using the setsockopt interface to set the key. For example, the
-     ansi_cprng requires a seed. The DRBGs do not require a seed, but
-     may be seeded.
-    </para>
-
-    <para>
-     Using the read()/recvmsg() system calls, random numbers can be obtained.
-     The kernel generates at most 128 bytes in one call. If user space
-     requires more data, multiple calls to read()/recvmsg() must be made.
-    </para>
-
-    <para>
-     WARNING: The user space caller may invoke the initially mentioned
-     accept system call multiple times. In this case, the returned file
-     descriptors have the same state.
-    </para>
-
-   </sect1>
-
-   <sect1><title>Zero-Copy Interface</title>
-    <para>
-     In addition to the send/write/read/recv system call family, the AF_ALG
-     interface can be accessed with the zero-copy interface of splice/vmsplice.
-     As the name indicates, the kernel tries to avoid a copy operation into
-     kernel space.
-    </para>
-
-    <para>
-     The zero-copy operation requires data to be aligned at the page boundary.
-     Non-aligned data can be used as well, but may require more operations of
-     the kernel which would defeat the speed gains obtained from the zero-copy
-     interface.
-    </para>
-
-    <para>
-     The system-interent limit for the size of one zero-copy operation is
-     16 pages. If more data is to be sent to AF_ALG, user space must slice
-     the input into segments with a maximum size of 16 pages.
-    </para>
-
-    <para>
-     Zero-copy can be used with the following code example (a complete working
-     example is provided with libkcapi):
-    </para>
-
-    <programlisting>
-int pipes[2];
-
-pipe(pipes);
-/* input data in iov */
-vmsplice(pipes[1], iov, iovlen, SPLICE_F_GIFT);
-/* opfd is the file descriptor returned from accept() system call */
-splice(pipes[0], NULL, opfd, NULL, ret, 0);
-read(opfd, out, outlen);
-    </programlisting>
-
-   </sect1>
-
-   <sect1><title>Setsockopt Interface</title>
-    <para>
-     In addition to the read/recv and send/write system call handling
-     to send and retrieve data subject to the cipher operation, a consumer
-     also needs to set the additional information for the cipher operation.
-     This additional information is set using the setsockopt system call
-     that must be invoked with the file descriptor of the open cipher
-     (i.e. the file descriptor returned by the accept system call).
-    </para>
-
-    <para>
-     Each setsockopt invocation must use the level SOL_ALG.
-    </para>
-
-    <para>
-     The setsockopt interface allows setting the following data using
-     the mentioned optname:
-    </para>
-
-    <itemizedlist>
-     <listitem>
-      <para>
-       ALG_SET_KEY -- Setting the key. Key setting is applicable to:
-      </para>
-      <itemizedlist>
-       <listitem>
-        <para>the skcipher cipher type (symmetric ciphers)</para>
-       </listitem>
-       <listitem>
-        <para>the hash cipher type (keyed message digests)</para>
-       </listitem>
-       <listitem>
-        <para>the AEAD cipher type</para>
-       </listitem>
-       <listitem>
-        <para>the RNG cipher type to provide the seed</para>
-       </listitem>
-      </itemizedlist>
-     </listitem>
-
-     <listitem>
-      <para>
-       ALG_SET_AEAD_AUTHSIZE -- Setting the authentication tag size
-       for AEAD ciphers. For a encryption operation, the authentication
-       tag of the given size will be generated. For a decryption operation,
-       the provided ciphertext is assumed to contain an authentication tag
-       of the given size (see section about AEAD memory layout below).
-      </para>
-     </listitem>
-    </itemizedlist>
-
-   </sect1>
-
-   <sect1><title>User space API example</title>
-    <para>
-     Please see [1] for libkcapi which provides an easy-to-use wrapper
-     around the aforementioned Netlink kernel interface. [1] also contains
-     a test application that invokes all libkcapi API calls.
-    </para>
-
-    <para>
-     [1] <ulink url="http://www.chronox.de/libkcapi.html">http://www.chronox.de/libkcapi.html</ulink>
-    </para>
-
-   </sect1>
-
-  </chapter>
-
   <chapter id="API"><title>Programming Interface</title>
-   <para>
-    Please note that the kernel crypto API contains the AEAD givcrypt
-    API (crypto_aead_giv* and aead_givcrypt_* function calls in
-    include/crypto/aead.h). This API is obsolete and will be removed
-    in the future. To obtain the functionality of an AEAD cipher with
-    internal IV generation, use the IV generator as a regular cipher.
-    For example, rfc4106(gcm(aes)) is the AEAD cipher with external
-    IV generation and seqniv(rfc4106(gcm(aes))) implies that the kernel
-    crypto API generates the IV. Different IV generators are available.
-   </para>
    <sect1><title>Block Cipher Context Data Structures</title>
 !Pinclude/linux/crypto.h Block Cipher Context Data Structures
-!Finclude/crypto/aead.h aead_request
+!Finclude/linux/crypto.h aead_request
    </sect1>
    <sect1><title>Block Cipher Algorithm Definitions</title>
 !Pinclude/linux/crypto.h Block Cipher Algorithm Definitions
 !Finclude/linux/crypto.h crypto_alg
 !Finclude/linux/crypto.h ablkcipher_alg
-!Finclude/crypto/aead.h aead_alg
+!Finclude/linux/crypto.h aead_alg
 !Finclude/linux/crypto.h blkcipher_alg
 !Finclude/linux/crypto.h cipher_alg
-!Finclude/crypto/rng.h rng_alg
+!Finclude/linux/crypto.h rng_alg
    </sect1>
    <sect1><title>Asynchronous Block Cipher API</title>
 !Pinclude/linux/crypto.h Asynchronous Block Cipher API
@@ -1714,27 +844,26 @@ read(opfd, out, outlen);
 !Finclude/linux/crypto.h ablkcipher_request_set_crypt
    </sect1>
    <sect1><title>Authenticated Encryption With Associated Data (AEAD) Cipher API</title>
-!Pinclude/crypto/aead.h Authenticated Encryption With Associated Data (AEAD) Cipher API
-!Finclude/crypto/aead.h crypto_alloc_aead
-!Finclude/crypto/aead.h crypto_free_aead
-!Finclude/crypto/aead.h crypto_aead_ivsize
-!Finclude/crypto/aead.h crypto_aead_authsize
-!Finclude/crypto/aead.h crypto_aead_blocksize
-!Finclude/crypto/aead.h crypto_aead_setkey
-!Finclude/crypto/aead.h crypto_aead_setauthsize
-!Finclude/crypto/aead.h crypto_aead_encrypt
-!Finclude/crypto/aead.h crypto_aead_decrypt
+!Pinclude/linux/crypto.h Authenticated Encryption With Associated Data (AEAD) Cipher API
+!Finclude/linux/crypto.h crypto_alloc_aead
+!Finclude/linux/crypto.h crypto_free_aead
+!Finclude/linux/crypto.h crypto_aead_ivsize
+!Finclude/linux/crypto.h crypto_aead_authsize
+!Finclude/linux/crypto.h crypto_aead_blocksize
+!Finclude/linux/crypto.h crypto_aead_setkey
+!Finclude/linux/crypto.h crypto_aead_setauthsize
+!Finclude/linux/crypto.h crypto_aead_encrypt
+!Finclude/linux/crypto.h crypto_aead_decrypt
    </sect1>
    <sect1><title>Asynchronous AEAD Request Handle</title>
-!Pinclude/crypto/aead.h Asynchronous AEAD Request Handle
-!Finclude/crypto/aead.h crypto_aead_reqsize
-!Finclude/crypto/aead.h aead_request_set_tfm
-!Finclude/crypto/aead.h aead_request_alloc
-!Finclude/crypto/aead.h aead_request_free
-!Finclude/crypto/aead.h aead_request_set_callback
-!Finclude/crypto/aead.h aead_request_set_crypt
-!Finclude/crypto/aead.h aead_request_set_assoc
-!Finclude/crypto/aead.h aead_request_set_ad
+!Pinclude/linux/crypto.h Asynchronous AEAD Request Handle
+!Finclude/linux/crypto.h crypto_aead_reqsize
+!Finclude/linux/crypto.h aead_request_set_tfm
+!Finclude/linux/crypto.h aead_request_alloc
+!Finclude/linux/crypto.h aead_request_free
+!Finclude/linux/crypto.h aead_request_set_callback
+!Finclude/linux/crypto.h aead_request_set_crypt
+!Finclude/linux/crypto.h aead_request_set_assoc
    </sect1>
    <sect1><title>Synchronous Block Cipher API</title>
 !Pinclude/linux/crypto.h Synchronous Block Cipher API

Documentation/DocBook/device-drivers.tmpl

@@ -66,7 +66,6 @@
 !Ekernel/time/hrtimer.c
      </sect1>
      <sect1><title>Workqueues and Kevents</title>
-!Iinclude/linux/workqueue.h
 !Ekernel/workqueue.c
      </sect1>
      <sect1><title>Internal Functions</title>
@@ -217,111 +216,6 @@ X!Isound/sound_firmware.c
 -->
   </chapter>
 
-  <chapter id="mediadev">
-     <title>Media Devices</title>
-
-     <sect1><title>Video2Linux devices</title>
-!Iinclude/media/tuner.h
-!Iinclude/media/tuner-types.h
-!Iinclude/media/tveeprom.h
-!Iinclude/media/v4l2-async.h
-!Iinclude/media/v4l2-ctrls.h
-!Iinclude/media/v4l2-dv-timings.h
-!Iinclude/media/v4l2-event.h
-!Iinclude/media/v4l2-flash-led-class.h
-!Iinclude/media/v4l2-mediabus.h
-!Iinclude/media/v4l2-mem2mem.h
-!Iinclude/media/v4l2-of.h
-!Iinclude/media/v4l2-subdev.h
-!Iinclude/media/videobuf2-core.h
-!Iinclude/media/videobuf2-v4l2.h
-!Iinclude/media/videobuf2-memops.h
-     </sect1>
-     <sect1><title>Digital TV (DVB) devices</title>
-!Idrivers/media/dvb-core/dvb_ca_en50221.h
-!Idrivers/media/dvb-core/dvb_frontend.h
-!Idrivers/media/dvb-core/dvb_math.h
-!Idrivers/media/dvb-core/dvb_ringbuffer.h
-!Idrivers/media/dvb-core/dvbdev.h
-	<sect1><title>Digital TV Demux API</title>
-	    <para>The kernel demux API defines a driver-internal interface for
-	    registering low-level, hardware specific driver to a hardware
-	    independent demux layer. It is only of interest for Digital TV
-	    device driver writers. The header file for this API is named
-	    <constant>demux.h</constant> and located in
-	    <constant>drivers/media/dvb-core</constant>.</para>
-
-	<para>The demux API should be implemented for each demux in the
-	system. It is used to select the TS source of a demux and to manage
-	the demux resources. When the demux client allocates a resource via
-	the demux API, it receives a pointer to the API of that
-	resource.</para>
-	<para>Each demux receives its TS input from a DVB front-end or from
-	memory, as set via this demux API. In a system with more than one
-	front-end, the API can be used to select one of the DVB front-ends
-	as a TS source for a demux, unless this is fixed in the HW platform.
-	The demux API only controls front-ends regarding to their connections
-	with demuxes; the APIs used to set the other front-end parameters,
-	such as tuning, are not defined in this document.</para>
-	<para>The functions that implement the abstract interface demux should
-	be defined static or module private and registered to the Demux
-	core for external access. It is not necessary to implement every
-	function in the struct <constant>dmx_demux</constant>. For example,
-	a demux interface might support Section filtering, but not PES
-	filtering. The API client is expected to check the value of any
-	function pointer before calling the function: the value of NULL means
-	that the &#8220;function is not available&#8221;.</para>
-	<para>Whenever the functions of the demux API modify shared data,
-	the possibilities of lost update and race condition problems should
-	be addressed, e.g. by protecting parts of code with mutexes.</para>
-	<para>Note that functions called from a bottom half context must not
-	sleep. Even a simple memory allocation without using GFP_ATOMIC can
-	result in a kernel thread being put to sleep if swapping is needed.
-	For example, the Linux kernel calls the functions of a network device
-	interface from a bottom half context. Thus, if a demux API function
-	is called from network device code, the function must not sleep.
-	</para>
-    </sect1>
-
-    <section id="demux_callback_api">
-	<title>Demux Callback API</title>
-	<para>This kernel-space API comprises the callback functions that
-	deliver filtered data to the demux client. Unlike the other DVB
-	kABIs, these functions are provided by the client and called from
-	the demux code.</para>
-	<para>The function pointers of this abstract interface are not
-	packed into a structure as in the other demux APIs, because the
-	callback functions are registered and used independent of each
-	other. As an example, it is possible for the API client to provide
-	several callback functions for receiving TS packets and no
-	callbacks for PES packets or sections.</para>
-	<para>The functions that implement the callback API need not be
-	re-entrant: when a demux driver calls one of these functions,
-	the driver is not allowed to call the function again before
-	the original call returns. If a callback is triggered by a
-	hardware interrupt, it is recommended to use the Linux
-	&#8220;bottom half&#8221; mechanism or start a tasklet instead of
-	making the callback function call directly from a hardware
-	interrupt.</para>
-	<para>This mechanism is implemented by
-	<link linkend='API-dmx-ts-cb'>dmx_ts_cb()</link> and
-	<link linkend='API-dmx-section-cb'>dmx_section_cb()</link>.</para>
-    </section>
-
-!Idrivers/media/dvb-core/demux.h
-    </sect1>
-    <sect1><title>Remote Controller devices</title>
-!Iinclude/media/rc-core.h
-!Iinclude/media/lirc_dev.h
-    </sect1>
-    <sect1><title>Media Controller devices</title>
-!Iinclude/media/media-device.h
-!Iinclude/media/media-devnode.h
-!Iinclude/media/media-entity.h
-    </sect1>
-
-  </chapter>
-
   <chapter id="uart16x50">
      <title>16x50 UART Driver</title>
 !Edrivers/tty/serial/serial_core.c
@@ -561,31 +455,4 @@ X!Ilib/fonts/fonts.c
 !Edrivers/hsi/hsi.c
   </chapter>
 
-  <chapter id="pwm">
-    <title>Pulse-Width Modulation (PWM)</title>
-    <para>
-      Pulse-width modulation is a modulation technique primarily used to
-      control power supplied to electrical devices.
-    </para>
-    <para>
-      The PWM framework provides an abstraction for providers and consumers
-      of PWM signals. A controller that provides one or more PWM signals is
-      registered as <structname>struct pwm_chip</structname>. Providers are
-      expected to embed this structure in a driver-specific structure. This
-      structure contains fields that describe a particular chip.
-    </para>
-    <para>
-      A chip exposes one or more PWM signal sources, each of which exposed
-      as a <structname>struct pwm_device</structname>. Operations can be
-      performed on PWM devices to control the period, duty cycle, polarity
-      and active state of the signal.
-    </para>
-    <para>
-      Note that PWM devices are exclusive resources: they can always only be
-      used by one consumer at a time.
-    </para>
-!Iinclude/linux/pwm.h
-!Edrivers/pwm/core.c
-  </chapter>
-
 </book>

Documentation/DocBook/filesystems.tmpl

@@ -146,30 +146,36 @@
 The journalling layer is  easy to use. You need to
 first of all create a journal_t data structure. There are
 two calls to do this dependent on how you decide to allocate the physical
-media on which the journal resides. The jbd2_journal_init_inode() call
-is for journals stored in filesystem inodes, or the jbd2_journal_init_dev()
-call can be used for journal stored on a raw device (in a continuous range
+media on which the journal resides. The journal_init_inode() call
+is for journals stored in filesystem inodes, or the journal_init_dev()
+call can be use for journal stored on a raw device (in a continuous range
 of blocks). A journal_t is a typedef for a struct pointer, so when
-you are finally finished make sure you call jbd2_journal_destroy() on it
+you are finally finished make sure you call journal_destroy() on it
 to free up any used kernel memory.
 </para>
 
 <para>
 Once you have got your journal_t object you need to 'mount' or load the journal
-file. The journalling layer expects the space for the journal was already
-allocated and initialized properly by the userspace tools.  When loading the
-journal you must call jbd2_journal_load() to process journal contents.  If the
-client file system detects the journal contents does not need to be processed
-(or even need not have valid contents), it may call jbd2_journal_wipe() to
-clear the journal contents before calling jbd2_journal_load().
+file, unless of course you haven't initialised it yet - in which case you
+need to call journal_create().
 </para>
 
 <para>
-Note that jbd2_journal_wipe(..,0) calls jbd2_journal_skip_recovery() for you if
-it detects any outstanding transactions in the journal and similarly
-jbd2_journal_load() will call jbd2_journal_recover() if necessary.  I would
-advise reading ext4_load_journal() in fs/ext4/super.c for examples on this
-stage.
+Most of the time however your journal file will already have been created, but
+before you load it you must call journal_wipe() to empty the journal file.
+Hang on, you say , what if the filesystem wasn't cleanly umount()'d . Well, it is the
+job of the client file system to detect this and skip the call to journal_wipe().
+</para>
+
+<para>
+In either case the next call should be to journal_load() which prepares the
+journal file for use. Note that journal_wipe(..,0) calls journal_skip_recovery()
+for you if it detects any outstanding transactions in the journal and similarly
+journal_load() will call journal_recover() if necessary.
+I would advise reading fs/ext3/super.c for examples on this stage.
+[RGG: Why is the journal_wipe() call necessary - doesn't this needlessly
+complicate the API. Or isn't a good idea for the journal layer to hide
+dirty mounts from the client fs]
 </para>
 
 <para>
@@ -183,41 +189,41 @@ You still need to actually journal your filesystem changes, this
 is done by wrapping them into transactions. Additionally you
 also need to wrap the modification of each of the buffers
 with calls to the journal layer, so it knows what the modifications
-you are actually making are. To do this use jbd2_journal_start() which
+you are actually making are. To do this use  journal_start() which
 returns a transaction handle.
 </para>
 
 <para>
-jbd2_journal_start()
-and its counterpart jbd2_journal_stop(), which indicates the end of a
-transaction are nestable calls, so you can reenter a transaction if necessary,
-but remember you must call jbd2_journal_stop() the same number of times as
-jbd2_journal_start() before the transaction is completed (or more accurately
-leaves the update phase). Ext4/VFS makes use of this feature to simplify
-handling of inode dirtying, quota support, etc.
+journal_start()
+and its counterpart journal_stop(), which indicates the end of a transaction
+are nestable calls, so you can reenter a transaction if necessary,
+but remember you must call journal_stop() the same number of times as
+journal_start() before the transaction is completed (or more accurately
+leaves the update phase). Ext3/VFS makes use of this feature to simplify
+quota support.
 </para>
 
 <para>
 Inside each transaction you need to wrap the modifications to the
 individual buffers (blocks). Before you start to modify a buffer you
-need to call jbd2_journal_get_{create,write,undo}_access() as appropriate,
+need to call journal_get_{create,write,undo}_access() as appropriate,
 this allows the journalling layer to copy the unmodified data if it
 needs to. After all the buffer may be part of a previously uncommitted
 transaction.
 At this point you are at last ready to modify a buffer, and once
-you are have done so you need to call jbd2_journal_dirty_{meta,}data().
+you are have done so you need to call journal_dirty_{meta,}data().
 Or if you've asked for access to a buffer you now know is now longer
-required to be pushed back on the device you can call jbd2_journal_forget()
+required to be pushed back on the device you can call journal_forget()
 in much the same way as you might have used bforget() in the past.
 </para>
 
 <para>
-A jbd2_journal_flush() may be called at any time to commit and checkpoint
+A journal_flush() may be called at any time to commit and checkpoint
 all your transactions.
 </para>
 
 <para>
-Then at umount time , in your put_super() you can then call jbd2_journal_destroy()
+Then at umount time , in your put_super() you can then call journal_destroy()
 to clean up your in-core journal object.
 </para>
 
@@ -225,74 +231,82 @@ to clean up your in-core journal object.
 Unfortunately there a couple of ways the journal layer can cause a deadlock.
 The first thing to note is that each task can only have
 a single outstanding transaction at any one time, remember nothing
-commits until the outermost jbd2_journal_stop(). This means
+commits until the outermost journal_stop(). This means
 you must complete the transaction at the end of each file/inode/address
 etc. operation you perform, so that the journalling system isn't re-entered
 on another journal. Since transactions can't be nested/batched
 across differing journals, and another filesystem other than
-yours (say ext4) may be modified in a later syscall.
+yours (say ext3) may be modified in a later syscall.
 </para>
 
 <para>
-The second case to bear in mind is that jbd2_journal_start() can
+The second case to bear in mind is that journal_start() can
 block if there isn't enough space in the journal for your transaction
 (based on the passed nblocks param) - when it blocks it merely(!) needs to
 wait for transactions to complete and be committed from other tasks,
-so essentially we are waiting for jbd2_journal_stop(). So to avoid
-deadlocks you must treat jbd2_journal_start/stop() as if they
+so essentially we are waiting for journal_stop(). So to avoid
+deadlocks you must treat journal_start/stop() as if they
 were semaphores and include them in your semaphore ordering rules to prevent
-deadlocks. Note that jbd2_journal_extend() has similar blocking behaviour to
-jbd2_journal_start() so you can deadlock here just as easily as on
-jbd2_journal_start().
+deadlocks. Note that journal_extend() has similar blocking behaviour to
+journal_start() so you can deadlock here just as easily as on journal_start().
 </para>
 
 <para>
 Try to reserve the right number of blocks the first time. ;-). This will
 be the maximum number of blocks you are going to touch in this transaction.
-I advise having a look at at least ext4_jbd.h to see the basis on which
-ext4 uses to make these decisions.
+I advise having a look at at least ext3_jbd.h to see the basis on which
+ext3 uses to make these decisions.
 </para>
 
 <para>
 Another wriggle to watch out for is your on-disk block allocation strategy.
-Why? Because, if you do a delete, you need to ensure you haven't reused any
-of the freed blocks until the transaction freeing these blocks commits. If you
-reused these blocks and crash happens, there is no way to restore the contents
-of the reallocated blocks at the end of the last fully committed transaction.
-
-One simple way of doing this is to mark blocks as free in internal in-memory
-block allocation structures only after the transaction freeing them commits.
-Ext4 uses journal commit callback for this purpose.
+why? Because, if you undo a delete, you need to ensure you haven't reused any
+of the freed blocks in a later transaction. One simple way of doing this
+is make sure any blocks you allocate only have checkpointed transactions
+listed against them. Ext3 does this in ext3_test_allocatable().
 </para>
 
 <para>
-With journal commit callbacks you can ask the journalling layer to call a
-callback function when the transaction is finally committed to disk, so that
-you can do some of your own management. You ask the journalling layer for
-calling the callback by simply setting journal->j_commit_callback function
-pointer and that function is called after each transaction commit. You can also
-use transaction->t_private_list for attaching entries to a transaction that
-need processing when the transaction commits.
-</para>
-
-<para>
-JBD2 also provides a way to block all transaction updates via
-jbd2_journal_{un,}lock_updates(). Ext4 uses this when it wants a window with a
-clean and stable fs for a moment.  E.g.
+Lock is also providing through journal_{un,}lock_updates(),
+ext3 uses this when it wants a window with a clean and stable fs for a moment.
+eg.
 </para>
 
 <programlisting>
 
-	jbd2_journal_lock_updates() //stop new stuff happening..
-	jbd2_journal_flush()        // checkpoint everything.
+	journal_lock_updates() //stop new stuff happening..
+	journal_flush()        // checkpoint everything.
 	..do stuff on stable fs
-	jbd2_journal_unlock_updates() // carry on with filesystem use.
+	journal_unlock_updates() // carry on with filesystem use.
 </programlisting>
 
 <para>
 The opportunities for abuse and DOS attacks with this should be obvious,
 if you allow unprivileged userspace to trigger codepaths containing these
 calls.
+</para>
+
+<para>
+A new feature of jbd since 2.5.25 is commit callbacks with the new
+journal_callback_set() function you can now ask the journalling layer
+to call you back when the transaction is finally committed to disk, so that
+you can do some of your own management. The key to this is the journal_callback
+struct, this maintains the internal callback information but you can
+extend it like this:-
+</para>
+<programlisting>
+	struct  myfs_callback_s {
+		//Data structure element required by jbd..
+		struct journal_callback for_jbd;
+		// Stuff for myfs allocated together.
+		myfs_inode*    i_commited;
+
+	}
+</programlisting>
+
+<para>
+this would be useful if you needed to know when data was committed to a
+particular inode.
 </para>
 
     </sect2>
@@ -305,6 +319,36 @@ being each mount, each modification (transaction) and each changed buffer
 to tell the journalling layer about them.
 </para>
 
+<para>
+Here is a some pseudo code to give you an idea of how it works, as
+an example.
+</para>
+
+<programlisting>
+  journal_t* my_jnrl = journal_create();
+  journal_init_{dev,inode}(jnrl,...)
+  if (clean) journal_wipe();
+  journal_load();
+
+   foreach(transaction) { /*transactions must be
+                            completed before
+                            a syscall returns to
+                            userspace*/
+
+          handle_t * xct=journal_start(my_jnrl);
+          foreach(bh) {
+                journal_get_{create,write,undo}_access(xact,bh);
+                if ( myfs_modify(bh) ) { /* returns true
+                                        if makes changes */
+                           journal_dirty_{meta,}data(xact,bh);
+                } else {
+                           journal_forget(bh);
+                }
+          }
+          journal_stop(xct);
+   }
+   journal_destroy(my_jrnl);
+</programlisting>
     </sect2>
 
     </sect1>
@@ -313,13 +357,13 @@ to tell the journalling layer about them.
      <title>Data Types</title>
      <para>
 	The journalling layer uses typedefs to 'hide' the concrete definitions
-	of the structures used. As a client of the JBD2 layer you can
+	of the structures used. As a client of the JBD layer you can
 	just rely on the using the pointer as a magic cookie  of some sort.
 
 	Obviously the hiding is not enforced as this is 'C'.
      </para>
 	<sect2 id="structures"><title>Structures</title>
-!Iinclude/linux/jbd2.h
+!Iinclude/linux/jbd.h
 	</sect2>
     </sect1>
 
@@ -331,11 +375,11 @@ to tell the journalling layer about them.
 	manage transactions
      </para>
 	<sect2 id="journal_level"><title>Journal Level</title>
-!Efs/jbd2/journal.c
-!Ifs/jbd2/recovery.c
+!Efs/jbd/journal.c
+!Ifs/jbd/recovery.c
 	</sect2>
 	<sect2 id="transaction_level"><title>Transasction Level</title>
-!Efs/jbd2/transaction.c
+!Efs/jbd/transaction.c
 	</sect2>
     </sect1>
     <sect1 id="see_also">