5 files changed, 220 insertions, 0 deletions

diff --git a/Documentation/ABI/removed/ip_queue b/Documentation/ABI/removed/ip_queue
new file mode 100644
index 000000000000..3243613bc2d2
--- /dev/null
+++ b/Documentation/ABI/removed/ip_queue
@@ -0,0 +1,9 @@
+What:           ip_queue
+Date:           finally removed in kernel v3.5.0
+Contact:        Pablo Neira Ayuso <pablo@netfilter.org>
+Description:
+        ip_queue has been replaced by nfnetlink_queue which provides
+        more advanced queueing mechanism to user-space. The ip_queue
+        module was already announced to become obsolete years ago.
+
+Users:
diff --git a/Documentation/ABI/testing/dev-kmsg b/Documentation/ABI/testing/dev-kmsg
new file mode 100644
index 000000000000..281ecc5f9709
--- /dev/null
+++ b/Documentation/ABI/testing/dev-kmsg
@@ -0,0 +1,90 @@
+What:           /dev/kmsg
+Date:           Mai 2012
+KernelVersion:  3.5
+Contact:        Kay Sievers <kay@vrfy.org>
+Description:    The /dev/kmsg character device node provides userspace access
+                to the kernel's printk buffer.
+
+                Injecting messages:
+                Every write() to the opened device node places a log entry in
+                the kernel's printk buffer.
+
+                The logged line can be prefixed with a <N> syslog prefix, which
+                carries the syslog priority and facility. The single decimal
+                prefix number is composed of the 3 lowest bits being the syslog
+                priority and the higher bits the syslog facility number.
+
+                If no prefix is given, the priority number is the default kernel
+                log priority and the facility number is set to LOG_USER (1). It
+                is not possible to inject messages from userspace with the
+                facility number LOG_KERN (0), to make sure that the origin of
+                the messages can always be reliably determined.
+
+                Accessing the buffer:
+                Every read() from the opened device node receives one record
+                of the kernel's printk buffer.
+
+                The first read() directly following an open() always returns
+                first message in the buffer; there is no kernel-internal
+                persistent state; many readers can concurrently open the device
+                and read from it, without affecting other readers.
+
+                Every read() will receive the next available record. If no more
+                records are available read() will block, or if O_NONBLOCK is
+                used -EAGAIN returned.
+
+                Messages in the record ring buffer get overwritten as whole,
+                there are never partial messages received by read().
+
+                In case messages get overwritten in the circular buffer while
+                the device is kept open, the next read() will return -EPIPE,
+                and the seek position be updated to the next available record.
+                Subsequent reads() will return available records again.
+
+                Unlike the classic syslog() interface, the 64 bit record
+                sequence numbers allow to calculate the amount of lost
+                messages, in case the buffer gets overwritten. And they allow
+                to reconnect to the buffer and reconstruct the read position
+                if needed, without limiting the interface to a single reader.
+
+                The device supports seek with the following parameters:
+                SEEK_SET, 0
+                  seek to the first entry in the buffer
+                SEEK_END, 0
+                  seek after the last entry in the buffer
+                SEEK_DATA, 0
+                  seek after the last record available at the time
+                  the last SYSLOG_ACTION_CLEAR was issued.
+
+                The output format consists of a prefix carrying the syslog
+                prefix including priority and facility, the 64 bit message
+                sequence number and the monotonic timestamp in microseconds.
+                The values are separated by a ','. Future extensions might
+                add more comma separated values before the terminating ';'.
+                Unknown values should be gracefully ignored.
+
+                The human readable text string starts directly after the ';'
+                and is terminated by a '\n'. Untrusted values derived from
+                hardware or other facilities are printed, therefore
+                all non-printable characters in the log message are escaped
+                by "\x00" C-style hex encoding.
+
+                A line starting with ' ', is a continuation line, adding
+                key/value pairs to the log message, which provide the machine
+                readable context of the message, for reliable processing in
+                userspace.
+
+                Example:
+                7,160,424069;pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7] (ignored)
+                 SUBSYSTEM=acpi
+                 DEVICE=+acpi:PNP0A03:00
+                6,339,5140900;NET: Registered protocol family 10
+                30,340,5690716;udevd[80]: starting version 181
+
+                The DEVICE= key uniquely identifies devices the following way:
+                  b12:8        - block dev_t
+                  c127:3       - char dev_t
+                  n8           - netdev ifindex
+                  +sound:card0 - subsystem:devname
+
+Users:          dmesg(1), userspace kernel log consumers
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index 7c22a532fdfb..6ae9fec8e07d 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -135,6 +135,17 @@ Description:
                 for the device and attempt to bind to it.  For example:
                 # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
 
+                Reading from this file will list all dynamically added
+                device IDs in the same format, with one entry per
+                line. For example:
+                # cat /sys/bus/usb/drivers/foo/new_id
+                8086 10f5
+                dead beef 06
+                f00d cafe
+
+                The list will be truncated at PAGE_SIZE bytes due to
+                sysfs restrictions.
+
 What:           /sys/bus/usb-serial/drivers/.../new_id
 Date:           October 2011
 Contact:        linux-usb@vger.kernel.org
@@ -157,6 +168,10 @@ Description:
                 match the driver to the device.  For example:
                 # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id
 
+                Reading from this file will list the dynamically added
+                device IDs, exactly like reading from the entry
+                "/sys/bus/usb/drivers/.../new_id"
+
 What:           /sys/bus/usb/device/.../avoid_reset_quirk
 Date:           December 2009
 Contact:        Oliver Neukum <oliver@neukum.org>
diff --git a/Documentation/ABI/testing/sysfs-class-extcon b/Documentation/ABI/testing/sysfs-class-extcon
new file mode 100644
index 000000000000..20ab361bd8c6
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-extcon
@@ -0,0 +1,97 @@
+What:           /sys/class/extcon/.../
+Date:           February 2012
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                Provide a place in sysfs for the extcon objects.
+                This allows accessing extcon specific variables.
+                The name of extcon object denoted as ... is the name given
+                with extcon_dev_register.
+
+                One extcon device denotes a single external connector
+                port. An external connector may have multiple cables
+                attached simultaneously. Many of docks, cradles, and
+                accessory cables have such capability. For example,
+                the 30-pin port of Nuri board (/arch/arm/mach-exynos)
+                may have both HDMI and Charger attached, or analog audio,
+                video, and USB cables attached simulteneously.
+
+                If there are cables mutually exclusive with each other,
+                such binary relations may be expressed with extcon_dev's
+                mutually_exclusive array.
+
+What:           /sys/class/extcon/.../name
+Date:           February 2012
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                The /sys/class/extcon/.../name shows the name of the extcon
+                object. If the extcon object has an optional callback
+                "show_name" defined, the callback will provide the name with
+                this sysfs node.
+
+What:           /sys/class/extcon/.../state
+Date:           February 2012
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                The /sys/class/extcon/.../state shows and stores the cable
+                attach/detach information of the corresponding extcon object.
+                If the extcon object has an optional callback "show_state"
+                defined, the showing function is overriden with the optional
+                callback.
+
+                If the default callback for showing function is used, the
+                format is like this:
+                # cat state
+                USB_OTG=1
+                HDMI=0
+                TA=1
+                EAR_JACK=0
+                #
+                In this example, the extcon device have USB_OTG and TA
+                cables attached and HDMI and EAR_JACK cables detached.
+
+                In order to update the state of an extcon device, enter a hex
+                state number starting with 0x.
+                 echo 0xHEX > state
+
+                This updates the whole state of the extcon dev.
+                Inputs of all the methods are required to meet the
+                mutually_exclusive contidions if they exist.
+
+                It is recommended to use this "global" state interface if
+                you need to enter the value atomically. The later state
+                interface associated with each cable cannot update
+                multiple cable states of an extcon device simultaneously.
+
+What:           /sys/class/extcon/.../cable.x/name
+Date:           February 2012
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                The /sys/class/extcon/.../cable.x/name shows the name of cable
+                "x" (integer between 0 and 31) of an extcon device.
+
+What:           /sys/class/extcon/.../cable.x/state
+Date:           February 2012
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                The /sys/class/extcon/.../cable.x/name shows and stores the
+                state of cable "x" (integer between 0 and 31) of an extcon
+                device. The state value is either 0 (detached) or 1
+                (attached).
+
+What:           /sys/class/extcon/.../mutually_exclusive/...
+Date:           December 2011
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                Shows the relations of mutually exclusiveness. For example,
+                if the mutually_exclusive array of extcon_dev is
+                {0x3, 0x5, 0xC, 0x0}, the, the output is:
+                # ls mutually_exclusive/
+                0x3
+                0x5
+                0xc
+                #
+
+                Note that mutually_exclusive is a sub-directory of the extcon
+                device and the file names under the mutually_exclusive
+                directory show the mutually-exclusive sets, not the contents
+                of the files.
diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh
index b218e0f8bdb3..c81fe89c4c46 100644
--- a/Documentation/ABI/testing/sysfs-class-net-mesh
+++ b/Documentation/ABI/testing/sysfs-class-net-mesh
@@ -14,6 +14,15 @@ Description:
                 mesh will be sent using multiple interfaces at the
                 same time (if available).
 
+What:           /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance
+Date:           November 2011
+Contact:        Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
+Description:
+                Indicates whether the bridge loop avoidance feature
+                is enabled. This feature detects and avoids loops
+                between the mesh and devices bridged with the soft
+                interface <mesh_iface>.
+
 What:           /sys/class/net/<mesh_iface>/mesh/fragmentation
 Date:           October 2010
 Contact:        Andreas Langer <an.langer@gmx.de>