13 files changed, 265 insertions, 14 deletions

diff --git a/Documentation/ABI/testing/debugfs-olpc b/Documentation/ABI/testing/debugfs-olpc
new file mode 100644
index 000000000000..bd76cc6d55f9
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-olpc
@@ -0,0 +1,16 @@
+What:           /sys/kernel/debug/olpc-ec/cmd
+Date:           Dec 2011
+KernelVersion:  3.4
+Contact:        devel@lists.laptop.org
+Description:
+
+A generic interface for executing OLPC Embedded Controller commands and
+reading their responses.
+
+To execute a command, write data with the format: CC:N A A A A
+CC is the (hex) command, N is the count of expected reply bytes, and A A A A
+are optional (hex) arguments.
+
+To read the response (if any), read from the generic node after executing
+a command. Hex reply bytes will be returned, *whether or not* they came from
+the immediately previous command.
diff --git a/Documentation/ABI/testing/sysfs-block-dm b/Documentation/ABI/testing/sysfs-block-dm
new file mode 100644
index 000000000000..87ca5691e29b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-block-dm
@@ -0,0 +1,25 @@
+What:           /sys/block/dm-<num>/dm/name
+Date:           January 2009
+KernelVersion:  2.6.29
+Contact:        dm-devel@redhat.com
+Description:    Device-mapper device name.
+                Read-only string containing mapped device name.
+Users:          util-linux, device-mapper udev rules
+
+What:           /sys/block/dm-<num>/dm/uuid
+Date:           January 2009
+KernelVersion:  2.6.29
+Contact:        dm-devel@redhat.com
+Description:    Device-mapper device UUID.
+                Read-only string containing DM-UUID or empty string
+                if DM-UUID is not set.
+Users:          util-linux, device-mapper udev rules
+
+What:           /sys/block/dm-<num>/dm/suspended
+Date:           June 2009
+KernelVersion:  2.6.31
+Contact:        dm-devel@redhat.com
+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
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
new file mode 100644
index 000000000000..079afc71363d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
@@ -0,0 +1,14 @@
+Where:          /sys/bus/event_source/devices/<dev>/format
+Date:           January 2012
+Kernel Version: 3.3
+Contact:        Jiri Olsa <jolsa@redhat.com>
+Description:
+                Attribute group to describe the magic bits that go into
+                perf_event_attr::config[012] for a particular pmu.
+                Each attribute of this group defines the 'hardware' bitmask
+                we want to export, so that userspace can deal with sane
+                name/value pairs.
+
+                Example: 'config1:1,6-10,44'
+                Defines contents of attribute that occupies bits 1,6-10,44 of
+                perf_event_attr::config1.
diff --git a/Documentation/ABI/testing/sysfs-bus-rpmsg b/Documentation/ABI/testing/sysfs-bus-rpmsg
new file mode 100644
index 000000000000..189e419a5a2d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-rpmsg
@@ -0,0 +1,75 @@
+What:           /sys/bus/rpmsg/devices/.../name
+Date:           June 2011
+KernelVersion:  3.3
+Contact:        Ohad Ben-Cohen <ohad@wizery.com>
+Description:
+                Every rpmsg device is a communication channel with a remote
+                processor. Channels are identified with a (textual) name,
+                which is maximum 32 bytes long (defined as RPMSG_NAME_SIZE in
+                rpmsg.h).
+
+                This sysfs entry contains the name of this channel.
+
+What:           /sys/bus/rpmsg/devices/.../src
+Date:           June 2011
+KernelVersion:  3.3
+Contact:        Ohad Ben-Cohen <ohad@wizery.com>
+Description:
+                Every rpmsg device is a communication channel with a remote
+                processor. Channels have a local ("source") rpmsg address,
+                and remote ("destination") rpmsg address. When an entity
+                starts listening on one end of a channel, it assigns it with
+                a unique rpmsg address (a 32 bits integer). This way when
+                inbound messages arrive to this address, the rpmsg core
+                dispatches them to the listening entity (a kernel driver).
+
+                This sysfs entry contains the src (local) rpmsg address
+                of this channel. If it contains 0xffffffff, then an address
+                wasn't assigned (can happen if no driver exists for this
+                channel).
+
+What:           /sys/bus/rpmsg/devices/.../dst
+Date:           June 2011
+KernelVersion:  3.3
+Contact:        Ohad Ben-Cohen <ohad@wizery.com>
+Description:
+                Every rpmsg device is a communication channel with a remote
+                processor. Channels have a local ("source") rpmsg address,
+                and remote ("destination") rpmsg address. When an entity
+                starts listening on one end of a channel, it assigns it with
+                a unique rpmsg address (a 32 bits integer). This way when
+                inbound messages arrive to this address, the rpmsg core
+                dispatches them to the listening entity.
+
+                This sysfs entry contains the dst (remote) rpmsg address
+                of this channel. If it contains 0xffffffff, then an address
+                wasn't assigned (can happen if the kernel driver that
+                is attached to this channel is exposing a service to the
+                remote processor. This make it a local rpmsg server,
+                and it is listening for inbound messages that may be sent
+                from any remote rpmsg client; it is not bound to a single
+                remote entity).
+
+What:           /sys/bus/rpmsg/devices/.../announce
+Date:           June 2011
+KernelVersion:  3.3
+Contact:        Ohad Ben-Cohen <ohad@wizery.com>
+Description:
+                Every rpmsg device is a communication channel with a remote
+                processor. Channels are identified by a textual name (see
+                /sys/bus/rpmsg/devices/.../name above) and have a local
+                ("source") rpmsg address, and remote ("destination") rpmsg
+                address.
+
+                A channel is first created when an entity, whether local
+                or remote, starts listening on it for messages (and is thus
+                called an rpmsg server).
+
+                When that happens, a "name service" announcement is sent
+                to the other processor, in order to let it know about the
+                creation of the channel (this way remote clients know they
+                can start sending messages).
+
+                This sysfs entry tells us whether the channel is a local
+                server channel that is announced (values are either
+                true or false).
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index b4f548792e32..7c22a532fdfb 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -182,3 +182,14 @@ Description:
                 USB2 hardware LPM is 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/.../removable
+Date:           February 2012
+Contact:        Matthew Garrett <mjg@redhat.com>
+Description:
+                Some information about whether a given USB device is
+                physically fixed to the platform can be inferred from a
+                combination of hub decriptor bits and platform-specific data
+                such as ACPI. This file will read either "removable" or
+                "fixed" if the information is available, and "unknown"
+                otherwise.
\ No newline at end of file
diff --git a/Documentation/ABI/testing/sysfs-class b/Documentation/ABI/testing/sysfs-class
index 4b0cb891e46e..676530fcf747 100644
--- a/Documentation/ABI/testing/sysfs-class
+++ b/Documentation/ABI/testing/sysfs-class
@@ -1,6 +1,6 @@
 What:           /sys/class/
 Date:           Febuary 2006
-Contact:        Greg Kroah-Hartman <gregkh@suse.de>
+Contact:        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
                 The /sys/class directory will consist of a group of
                 subdirectories describing individual classes of devices
diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh
index b02001488eef..b218e0f8bdb3 100644
--- a/Documentation/ABI/testing/sysfs-class-net-mesh
+++ b/Documentation/ABI/testing/sysfs-class-net-mesh
@@ -65,6 +65,13 @@ Description:
                 Defines the penalty which will be applied to an
                 originator message's tq-field on every hop.
 
+What:           /sys/class/net/<mesh_iface>/mesh/routing_algo
+Date:           Dec 2011
+Contact:        Marek Lindner <lindner_marek@yahoo.de>
+Description:
+                Defines the routing procotol this mesh instance
+                uses to find the optimal paths through the mesh.
+
 What:           /sys/class/net/<mesh_iface>/mesh/vis_mode
 Date:           May 2010
 Contact:        Marek Lindner <lindner_marek@yahoo.de>
diff --git a/Documentation/ABI/testing/sysfs-devices b/Documentation/ABI/testing/sysfs-devices
index 6a25671ee5f6..5fcc94358b8d 100644
--- a/Documentation/ABI/testing/sysfs-devices
+++ b/Documentation/ABI/testing/sysfs-devices
@@ -1,6 +1,6 @@
 What:           /sys/devices
 Date:           February 2006
-Contact:        Greg Kroah-Hartman <gregkh@suse.de>
+Contact:        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
                 The /sys/devices tree contains a snapshot of the
                 internal state of the kernel device tree.  Devices will
diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power
index 8ffbc25376a0..840f7d64d483 100644
--- a/Documentation/ABI/testing/sysfs-devices-power
+++ b/Documentation/ABI/testing/sysfs-devices-power
@@ -165,3 +165,21 @@ Description:
 
                 Not all drivers support this attribute.  If it isn't supported,
                 attempts to read or write it will yield I/O errors.
+
+What:           /sys/devices/.../power/pm_qos_latency_us
+Date:           March 2012
+Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Description:
+                The /sys/devices/.../power/pm_qos_resume_latency_us attribute
+                contains the PM QoS resume latency limit for the given device,
+                which is the maximum allowed time it can take to resume the
+                device, after it has been suspended at run time, from a resume
+                request to the moment the device will be ready to process I/O,
+                in microseconds.  If it is equal to 0, however, this means that
+                the PM QoS resume latency may be arbitrary.
+
+                Not all drivers support this attribute.  If it isn't supported,
+                it is not present.
+
+                This attribute has no effect on system-wide suspend/resume and
+                hibernation.
diff --git a/Documentation/ABI/testing/sysfs-devices-soc b/Documentation/ABI/testing/sysfs-devices-soc
new file mode 100644
index 000000000000..6d9cc253f2b2
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-soc
@@ -0,0 +1,58 @@
+What:           /sys/devices/socX
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                The /sys/devices/ directory contains a sub-directory for each
+                System-on-Chip (SoC) device on a running platform. Information
+                regarding each SoC can be obtained by reading sysfs files. This
+                functionality is only available if implemented by the platform.
+
+                The directory created for each SoC will also house information
+                about devices which are commonly contained in /sys/devices/platform.
+                It has been agreed that if an SoC device exists, its supported
+                devices would be better suited to appear as children of that SoC.
+
+What:           /sys/devices/socX/machine
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                Read-only attribute common to all SoCs. Contains the SoC machine
+                name (e.g. Ux500).
+
+What:           /sys/devices/socX/family
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                Read-only attribute common to all SoCs. Contains SoC family name
+                (e.g. DB8500).
+
+What:           /sys/devices/socX/soc_id
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                Read-only attribute supported by most SoCs. In the case of
+                ST-Ericsson's chips this contains the SoC serial number.
+
+What:           /sys/devices/socX/revision
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                Read-only attribute supported by most SoCs. Contains the SoC's
+                manufacturing revision number.
+
+What:           /sys/devices/socX/process
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                Read-only attribute supported ST-Ericsson's silicon. Contains the
+                the process by which the silicon chip was manufactured.
+
+What:           /sys/bus/soc
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                The /sys/bus/soc/ directory contains the usual sub-folders
+                expected under most buses. /sys/bus/soc/devices is of particular
+                interest, as it contains a symlink for each SoC device found on
+                the system. Each symlink points back into the aforementioned
+                /sys/devices/socX devices.
diff --git a/Documentation/ABI/testing/sysfs-driver-samsung-laptop b/Documentation/ABI/testing/sysfs-driver-samsung-laptop
index 0a810231aad4..678819a3f8bf 100644
--- a/Documentation/ABI/testing/sysfs-driver-samsung-laptop
+++ b/Documentation/ABI/testing/sysfs-driver-samsung-laptop
@@ -1,7 +1,7 @@
 What:           /sys/devices/platform/samsung/performance_level
 Date:           January 1, 2010
 KernelVersion:  2.6.33
-Contact:        Greg Kroah-Hartman <gregkh@suse.de>
+Contact:        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:    Some Samsung laptops have different "performance levels"
                 that are can be modified by a function key, and by this
                 sysfs file.  These values don't always make a whole lot
@@ -17,3 +17,21 @@ Description:	Some Samsung laptops have different "performance levels"
                 Specifically, not all support the "overclock" option,
                 and it's still unknown if this value even changes
                 anything, other than making the user feel a bit better.
+
+What:           /sys/devices/platform/samsung/battery_life_extender
+Date:           December 1, 2011
+KernelVersion:  3.3
+Contact:        Corentin Chary <corentin.chary@gmail.com>
+Description:    Max battery charge level can be modified, battery cycle
+                life can be extended by reducing the max battery charge
+                level.
+                0 means normal battery mode (100% charge)
+                1 means battery life extender mode (80% charge)
+
+What:           /sys/devices/platform/samsung/usb_charge
+Date:           December 1, 2011
+KernelVersion:  3.3
+Contact:        Corentin Chary <corentin.chary@gmail.com>
+Description:    Use your USB ports to charge devices, even
+                when your laptop is powered off.
+                1 means enabled, 0 means disabled.
diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi
index 4f9ba3c2fca7..dd930c8db41f 100644
--- a/Documentation/ABI/testing/sysfs-firmware-acpi
+++ b/Documentation/ABI/testing/sysfs-firmware-acpi
@@ -1,3 +1,23 @@
+What:           /sys/firmware/acpi/bgrt/
+Date:           January 2012
+Contact:        Matthew Garrett <mjg@redhat.com>
+Description:
+                The BGRT is an ACPI 5.0 feature that allows the OS
+                to obtain a copy of the firmware boot splash and
+                some associated metadata. This is intended to be used
+                by boot splash applications in order to interact with
+                the firmware boot splash in order to avoid jarring
+                transitions.
+
+                image: The image bitmap. Currently a 32-bit BMP.
+                status: 1 if the image is valid, 0 if firmware invalidated it.
+                type: 0 indicates image is in BMP format.
+                version: The version of the BGRT. Currently 1.
+                xoffset: The number of pixels between the left of the screen
+                         and the left edge of the image.
+                yoffset: The number of pixels between the top of the screen
+                         and the top edge of the image.
+
 What:           /sys/firmware/acpi/interrupts/
 Date:           February 2008
 Contact:        Len Brown <lenb@kernel.org>
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-cleancache b/Documentation/ABI/testing/sysfs-kernel-mm-cleancache
deleted file mode 100644
index 662ae646ea12..000000000000
--- a/Documentation/ABI/testing/sysfs-kernel-mm-cleancache
+++ /dev/null
@@ -1,11 +0,0 @@
-What:           /sys/kernel/mm/cleancache/
-Date:           April 2011
-Contact:        Dan Magenheimer <dan.magenheimer@oracle.com>
-Description:
-                /sys/kernel/mm/cleancache/ contains a number of files which
-                record a count of various cleancache operations
-                (sum across all filesystems):
-                        succ_gets
-                        failed_gets
-                        puts
-                        flushes