Merge branch 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6

* 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6: (50 commits)
  printk: do not mangle valid userspace syslog prefixes
  efivars: Add Documentation
  efivars: Expose efivars functionality to external drivers.
  efivars: Parameterize operations.
  efivars: Split out variable registration
  efivars: parameterize efivars
  efivars: Make efivars bin_attributes dynamic
  efivars: move efivars globals into struct efivars
  drivers:misc: ti-st: fix debugging code
  kref: Fix typo in kref documentation
  UIO: add PRUSS UIO driver support
  Fix spelling mistakes in Documentation/zh_CN/SubmittingPatches
  firmware: Fix unaligned memory accesses in dmi-sysfs
  firmware: Add documentation for /sys/firmware/dmi
  firmware: Expose DMI type 15 System Event Log
  firmware: Break out system_event_log in dmi-sysfs
  firmware: Basic dmi-sysfs support
  firmware: Add DMI entry types to the headers
  Driver core: convert platform_{get,set}_drvdata to static inline functions
  Translate linux-2.6/Documentation/magic-number.txt into Chinese
  ...

3 files changed, 233 insertions, 0 deletions

diff --git a/Documentation/ABI/stable/sysfs-firmware-efi-vars b/Documentation/ABI/stable/sysfs-firmware-efi-vars
new file mode 100644
index 000000000000..5def20b9019e
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-firmware-efi-vars
@@ -0,0 +1,75 @@
+What:           /sys/firmware/efi/vars
+Date:           April 2004
+Contact:        Matt Domsch <Matt_Domsch@dell.com>
+Description:
+                This directory exposes interfaces for interactive with
+                EFI variables.  For more information on EFI variables,
+                see 'Variable Services' in the UEFI specification
+                (section 7.2 in specification version 2.3 Errata D).
+
+                In summary, EFI variables are named, and are classified
+                into separate namespaces through the use of a vendor
+                GUID.  They also have an arbitrary binary value
+                associated with them.
+
+                The efivars module enumerates these variables and
+                creates a separate directory for each one found.  Each
+                directory has a name of the form "<key>-<vendor guid>"
+                and contains the following files:
+
+                attributes:     A read-only text file enumerating the
+                                EFI variable flags.  Potential values
+                                include:
+
+                                EFI_VARIABLE_NON_VOLATILE
+                                EFI_VARIABLE_BOOTSERVICE_ACCESS
+                                EFI_VARIABLE_RUNTIME_ACCESS
+                                EFI_VARIABLE_HARDWARE_ERROR_RECORD
+                                EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
+
+                                See the EFI documentation for an
+                                explanation of each of these variables.
+
+                data:           A read-only binary file that can be read
+                                to attain the value of the EFI variable
+
+                guid:           The vendor GUID of the variable.  This
+                                should always match the GUID in the
+                                variable's name.
+
+                raw_var:        A binary file that can be read to obtain
+                                a structure that contains everything
+                                there is to know about the variable.
+                                For structure definition see "struct
+                                efi_variable" in the kernel sources.
+
+                                This file can also be written to in
+                                order to update the value of a variable.
+                                For this to work however, all fields of
+                                the "struct efi_variable" passed must
+                                match byte for byte with the structure
+                                read out of the file, save for the value
+                                portion.
+
+                                **Note** the efi_variable structure
+                                read/written with this file contains a
+                                'long' type that may change widths
+                                depending on your underlying
+                                architecture.
+
+                size:           As ASCII representation of the size of
+                                the variable's value.
+
+
+                In addition, two other magic binary files are provided
+                in the top-level directory and are used for adding and
+                removing variables:
+
+                new_var:        Takes a "struct efi_variable" and
+                                instructs the EFI firmware to create a
+                                new variable.
+
+                del_var:        Takes a "struct efi_variable" and
+                                instructs the EFI firmware to remove any
+                                variable that has a matching vendor GUID
+                                and variable key name.
diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi b/Documentation/ABI/testing/sysfs-firmware-dmi
new file mode 100644
index 000000000000..ba9da9503c23
--- /dev/null
+++ b/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 '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 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 position of the entry within the entirety
+                          of the entirety.
+
+                === Entry Specialization ===
+
+                Some entry types may have other information available in
+                sysfs.
+
+                --- 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 entries 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.
diff --git a/Documentation/ABI/testing/sysfs-platform-kim b/Documentation/ABI/testing/sysfs-platform-kim
new file mode 100644
index 000000000000..c1653271872a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-kim
@@ -0,0 +1,48 @@
+What:           /sys/devices/platform/kim/dev_name
+Date:           January 2010
+KernelVersion:  2.6.38
+Contact:        "Pavan Savoy" <pavan_savoy@ti.com>
+Description:
+                Name of the UART device at which the WL128x chip
+                is connected. example: "/dev/ttyS0".
+                The device name flows down to architecture specific board
+                initialization file from the SFI/ATAGS bootloader
+                firmware. The name exposed is read from the user-space
+                dameon and opens the device when install is requested.
+
+What:           /sys/devices/platform/kim/baud_rate
+Date:           January 2010
+KernelVersion:  2.6.38
+Contact:        "Pavan Savoy" <pavan_savoy@ti.com>
+Description:
+                The maximum reliable baud-rate the host can support.
+                Different platforms tend to have different high-speed
+                UART configurations, so the baud-rate needs to be set
+                locally and also sent across to the WL128x via a HCI-VS
+                command. The entry is read and made use by the user-space
+                daemon when the ldisc install is requested.
+
+What:           /sys/devices/platform/kim/flow_cntrl
+Date:           January 2010
+KernelVersion:  2.6.38
+Contact:        "Pavan Savoy" <pavan_savoy@ti.com>
+Description:
+                The WL128x makes use of flow control mechanism, and this
+                entry most often should be 1, the host's UART is required
+                to have the capability of flow-control, or else this
+                entry can be made use of for exceptions.
+
+What:           /sys/devices/platform/kim/install
+Date:           January 2010
+KernelVersion:  2.6.38
+Contact:        "Pavan Savoy" <pavan_savoy@ti.com>
+Description:
+                When one of the protocols Bluetooth, FM or GPS wants to make
+                use of the shared UART transport, it registers to the shared
+                transport driver, which will signal the user-space for opening,
+                configuring baud and install line discipline via this sysfs
+                entry. This entry would be polled upon by the user-space
+                daemon managing the UART, and is notified about the change
+                by the sysfs_notify. The value would be '1' when UART needs
+                to be opened/ldisc installed, and would be '0' when UART
+                is no more required and needs to be closed.