4 files changed, 243 insertions, 10 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-devices-power b/Documentation/ABI/testing/sysfs-devices-power
index 7628cd1bc36a..8ffbc25376a0 100644
--- a/Documentation/ABI/testing/sysfs-devices-power
+++ b/Documentation/ABI/testing/sysfs-devices-power
@@ -29,9 +29,8 @@ Description:
                "disabled" to it.
                For the devices that are not capable of generating system wakeup
-                events this file contains "\n".  In that cases the user space
+                events this file is not present.  In that case the device cannot
-                cannot modify the contents of this file and the device cannot be
+                be enabled to wake up the system from sleep states.
-                enabled to wake up the system.
 What:           /sys/devices/.../power/control
 Date:           January 2009
@@ -85,7 +84,7 @@ Description:
                The /sys/devices/.../wakeup_count attribute contains the number
                of signaled wakeup events associated with the device.  This
                attribute is read-only.  If the device is not enabled to wake up
-                the system from sleep states, this attribute is empty.
+                the system from sleep states, this attribute is not present.
 What:           /sys/devices/.../power/wakeup_active_count
 Date:           September 2010
@@ -95,7 +94,7 @@ Description:
                number of times the processing of wakeup events associated with
                the device was completed (at the kernel level).  This attribute
                is read-only.  If the device is not enabled to wake up the
-                system from sleep states, this attribute is empty.
+                system from sleep states, this attribute is not present.
 What:           /sys/devices/.../power/wakeup_hit_count
 Date:           September 2010
@@ -105,7 +104,8 @@ Description:
                number of times the processing of a wakeup event associated with
                the device might prevent the system from entering a sleep state.
                This attribute is read-only.  If the device is not enabled to
-                wake up the system from sleep states, this attribute is empty.
+                wake up the system from sleep states, this attribute is not
+                present.
 What:           /sys/devices/.../power/wakeup_active
 Date:           September 2010
@@ -115,7 +115,7 @@ Description:
                or 0, depending on whether or not a wakeup event associated with
                the device is being processed (1).  This attribute is read-only.
                If the device is not enabled to wake up the system from sleep
-                states, this attribute is empty.
+                states, this attribute is not present.
 What:           /sys/devices/.../power/wakeup_total_time_ms
 Date:           September 2010
@@ -125,7 +125,7 @@ Description:
                the total time of processing wakeup events associated with the
                device, in milliseconds.  This attribute is read-only.  If the
                device is not enabled to wake up the system from sleep states,
-                this attribute is empty.
+                this attribute is not present.
 What:           /sys/devices/.../power/wakeup_max_time_ms
 Date:           September 2010
@@ -135,7 +135,7 @@ Description:
                the maximum time of processing a single wakeup event associated
                with the device, in milliseconds.  This attribute is read-only.
                If the device is not enabled to wake up the system from sleep
-                states, this attribute is empty.
+                states, this attribute is not present.
 What:           /sys/devices/.../power/wakeup_last_time_ms
 Date:           September 2010
@@ -146,7 +146,7 @@ Description:
                signaling the last wakeup event associated with the device, in
                milliseconds.  This attribute is read-only.  If the device is
                not enabled to wake up the system from sleep states, this
-                attribute is empty.
+                attribute is not present.
 What:           /sys/devices/.../power/autosuspend_delay_ms
 Date:           September 2010
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.

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 @@
		1	What: /sys/firmware/efi/vars
		2	Date: April 2004
		3	Contact: Matt Domsch <Matt_Domsch@dell.com>
		4	Description:
		5	This directory exposes interfaces for interactive with
		6	EFI variables. For more information on EFI variables,
		7	see 'Variable Services' in the UEFI specification
		8	(section 7.2 in specification version 2.3 Errata D).
		9
		10	In summary, EFI variables are named, and are classified
		11	into separate namespaces through the use of a vendor
		12	GUID. They also have an arbitrary binary value
		13	associated with them.
		14
		15	The efivars module enumerates these variables and
		16	creates a separate directory for each one found. Each
		17	directory has a name of the form "<key>-<vendor guid>"
		18	and contains the following files:
		19
		20	attributes: A read-only text file enumerating the
		21	EFI variable flags. Potential values
		22	include:
		23
		24	EFI_VARIABLE_NON_VOLATILE
		25	EFI_VARIABLE_BOOTSERVICE_ACCESS
		26	EFI_VARIABLE_RUNTIME_ACCESS
		27	EFI_VARIABLE_HARDWARE_ERROR_RECORD
		28	EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
		29
		30	See the EFI documentation for an
		31	explanation of each of these variables.
		32
		33	data: A read-only binary file that can be read
		34	to attain the value of the EFI variable
		35
		36	guid: The vendor GUID of the variable. This
		37	should always match the GUID in the
		38	variable's name.
		39
		40	raw_var: A binary file that can be read to obtain
		41	a structure that contains everything
		42	there is to know about the variable.
		43	For structure definition see "struct
		44	efi_variable" in the kernel sources.
		45
		46	This file can also be written to in
		47	order to update the value of a variable.
		48	For this to work however, all fields of
		49	the "struct efi_variable" passed must
		50	match byte for byte with the structure
		51	read out of the file, save for the value
		52	portion.
		53
		54	Note the efi_variable structure
		55	read/written with this file contains a
		56	'long' type that may change widths
		57	depending on your underlying
		58	architecture.
		59
		60	size: As ASCII representation of the size of
		61	the variable's value.
		62
		63
		64	In addition, two other magic binary files are provided
		65	in the top-level directory and are used for adding and
		66	removing variables:
		67
		68	new_var: Takes a "struct efi_variable" and
		69	instructs the EFI firmware to create a
		70	new variable.
		71
		72	del_var: Takes a "struct efi_variable" and
		73	instructs the EFI firmware to remove any
		74	variable that has a matching vendor GUID
		75	and variable key name.


diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 7628cd1bc36a..8ffbc25376a0 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power
@@ -29,9 +29,8 @@ Description:
29	"disabled" to it.	29	"disabled" to it.
30		30
31	For the devices that are not capable of generating system wakeup	31	For the devices that are not capable of generating system wakeup
32	events this file contains "\n". In that cases the user space	32	events this file is not present. In that case the device cannot
33	cannot modify the contents of this file and the device cannot be	33	be enabled to wake up the system from sleep states.
34	enabled to wake up the system.
35		34
36	What: /sys/devices/.../power/control	35	What: /sys/devices/.../power/control
37	Date: January 2009	36	Date: January 2009
@@ -85,7 +84,7 @@ Description:
85	The /sys/devices/.../wakeup_count attribute contains the number	84	The /sys/devices/.../wakeup_count attribute contains the number
86	of signaled wakeup events associated with the device. This	85	of signaled wakeup events associated with the device. This
87	attribute is read-only. If the device is not enabled to wake up	86	attribute is read-only. If the device is not enabled to wake up
88	the system from sleep states, this attribute is empty.	87	the system from sleep states, this attribute is not present.
89		88
90	What: /sys/devices/.../power/wakeup_active_count	89	What: /sys/devices/.../power/wakeup_active_count
91	Date: September 2010	90	Date: September 2010
@@ -95,7 +94,7 @@ Description:
95	number of times the processing of wakeup events associated with	94	number of times the processing of wakeup events associated with
96	the device was completed (at the kernel level). This attribute	95	the device was completed (at the kernel level). This attribute
97	is read-only. If the device is not enabled to wake up the	96	is read-only. If the device is not enabled to wake up the
98	system from sleep states, this attribute is empty.	97	system from sleep states, this attribute is not present.
99		98
100	What: /sys/devices/.../power/wakeup_hit_count	99	What: /sys/devices/.../power/wakeup_hit_count
101	Date: September 2010	100	Date: September 2010
@@ -105,7 +104,8 @@ Description:
105	number of times the processing of a wakeup event associated with	104	number of times the processing of a wakeup event associated with
106	the device might prevent the system from entering a sleep state.	105	the device might prevent the system from entering a sleep state.
107	This attribute is read-only. If the device is not enabled to	106	This attribute is read-only. If the device is not enabled to
108	wake up the system from sleep states, this attribute is empty.	107	wake up the system from sleep states, this attribute is not
		108	present.
109		109
110	What: /sys/devices/.../power/wakeup_active	110	What: /sys/devices/.../power/wakeup_active
111	Date: September 2010	111	Date: September 2010
@@ -115,7 +115,7 @@ Description:
115	or 0, depending on whether or not a wakeup event associated with	115	or 0, depending on whether or not a wakeup event associated with
116	the device is being processed (1). This attribute is read-only.	116	the device is being processed (1). This attribute is read-only.
117	If the device is not enabled to wake up the system from sleep	117	If the device is not enabled to wake up the system from sleep
118	states, this attribute is empty.	118	states, this attribute is not present.
119		119
120	What: /sys/devices/.../power/wakeup_total_time_ms	120	What: /sys/devices/.../power/wakeup_total_time_ms
121	Date: September 2010	121	Date: September 2010
@@ -125,7 +125,7 @@ Description:
125	the total time of processing wakeup events associated with the	125	the total time of processing wakeup events associated with the
126	device, in milliseconds. This attribute is read-only. If the	126	device, in milliseconds. This attribute is read-only. If the
127	device is not enabled to wake up the system from sleep states,	127	device is not enabled to wake up the system from sleep states,
128	this attribute is empty.	128	this attribute is not present.
129		129
130	What: /sys/devices/.../power/wakeup_max_time_ms	130	What: /sys/devices/.../power/wakeup_max_time_ms
131	Date: September 2010	131	Date: September 2010
@@ -135,7 +135,7 @@ Description:
135	the maximum time of processing a single wakeup event associated	135	the maximum time of processing a single wakeup event associated
136	with the device, in milliseconds. This attribute is read-only.	136	with the device, in milliseconds. This attribute is read-only.
137	If the device is not enabled to wake up the system from sleep	137	If the device is not enabled to wake up the system from sleep
138	states, this attribute is empty.	138	states, this attribute is not present.
139		139
140	What: /sys/devices/.../power/wakeup_last_time_ms	140	What: /sys/devices/.../power/wakeup_last_time_ms
141	Date: September 2010	141	Date: September 2010
@@ -146,7 +146,7 @@ Description:
146	signaling the last wakeup event associated with the device, in	146	signaling the last wakeup event associated with the device, in
147	milliseconds. This attribute is read-only. If the device is	147	milliseconds. This attribute is read-only. If the device is
148	not enabled to wake up the system from sleep states, this	148	not enabled to wake up the system from sleep states, this
149	attribute is empty.	149	attribute is not present.
150		150
151	What: /sys/devices/.../power/autosuspend_delay_ms	151	What: /sys/devices/.../power/autosuspend_delay_ms
152	Date: September 2010	152	Date: September 2010


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 @@
		1	What: /sys/firmware/dmi/
		2	Date: February 2011
		3	Contact: Mike Waychison <mikew@google.com>
		4	Description:
		5	Many machines' firmware (x86 and ia64) export DMI /
		6	SMBIOS tables to the operating system. Getting at this
		7	information is often valuable to userland, especially in
		8	cases where there are OEM extensions used.
		9
		10	The kernel itself does not rely on the majority of the
		11	information in these tables being correct. It equally
		12	cannot ensure that the data as exported to userland is
		13	without error either.
		14
		15	DMI is structured as a large table of entries, where
		16	each entry has a common header indicating the type and
		17	length of the entry, as well as 'handle' that is
		18	supposed to be unique amongst all entries.
		19
		20	Some entries are required by the specification, but many
		21	others are optional. In general though, users should
		22	never expect to find a specific entry type on their
		23	system unless they know for certain what their firmware
		24	is doing. Machine to machine will vary.
		25
		26	Multiple entries of the same type are allowed. In order
		27	to handle these duplicate entry types, each entry is
		28	assigned by the operating system an 'instance', which is
		29	derived from an entry type's ordinal position. That is
		30	to say, if there are 'N' multiple entries with the same type
		31	'T' in the DMI tables (adjacent or spread apart, it
		32	doesn't matter), they will be represented in sysfs as
		33	entries "T-0" through "T-(N-1)":
		34
		35	Example entry directories:
		36
		37	/sys/firmware/dmi/entries/17-0
		38	/sys/firmware/dmi/entries/17-1
		39	/sys/firmware/dmi/entries/17-2
		40	/sys/firmware/dmi/entries/17-3
		41	...
		42
		43	Instance numbers are used in lieu of the firmware
		44	assigned entry handles as the kernel itself makes no
		45	guarantees that handles as exported are unique, and
		46	there are likely firmware images that get this wrong in
		47	the wild.
		48
		49	Each DMI entry in sysfs has the common header values
		50	exported as attributes:
		51
		52	handle : The 16bit 'handle' that is assigned to this
		53	entry by the firmware. This handle may be
		54	referred to by other entries.
		55	length : The length of the entry, as presented in the
		56	entry itself. Note that this is _not the
		57	total count of bytes associated with the
		58	entry_. This value represents the length of
		59	the "formatted" portion of the entry. This
		60	"formatted" region is sometimes followed by
		61	the "unformatted" region composed of nul
		62	terminated strings, with termination signalled
		63	by a two nul characters in series.
		64	raw : The raw bytes of the entry. This includes the
		65	"formatted" portion of the entry, the
		66	"unformatted" strings portion of the entry,
		67	and the two terminating nul characters.
		68	type : The type of the entry. This value is the same
		69	as found in the directory name. It indicates
		70	how the rest of the entry should be
		71	interpreted.
		72	instance: The instance ordinal of the entry for the
		73	given type. This value is the same as found
		74	in the parent directory name.
		75	position: The position of the entry within the entirety
		76	of the entirety.
		77
		78	=== Entry Specialization ===
		79
		80	Some entry types may have other information available in
		81	sysfs.
		82
		83	--- Type 15 - System Event Log ---
		84
		85	This entry allows the firmware to export a log of
		86	events the system has taken. This information is
		87	typically backed by nvram, but the implementation
		88	details are abstracted by this table. This entries data
		89	is exported in the directory:
		90
		91	/sys/firmware/dmi/entries/15-0/system_event_log
		92
		93	and has the following attributes (documented in the
		94	SMBIOS / DMI specification under "System Event Log (Type 15)":
		95
		96	area_length
		97	header_start_offset
		98	data_start_offset
		99	access_method
		100	status
		101	change_token
		102	access_method_address
		103	header_format
		104	per_log_type_descriptor_length
		105	type_descriptors_supported_count
		106
		107	As well, the kernel exports the binary attribute:
		108
		109	raw_event_log : The raw binary bits of the event log
		110	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 @@
		1	What: /sys/devices/platform/kim/dev_name
		2	Date: January 2010
		3	KernelVersion: 2.6.38
		4	Contact: "Pavan Savoy" <pavan_savoy@ti.com>
		5	Description:
		6	Name of the UART device at which the WL128x chip
		7	is connected. example: "/dev/ttyS0".
		8	The device name flows down to architecture specific board
		9	initialization file from the SFI/ATAGS bootloader
		10	firmware. The name exposed is read from the user-space
		11	dameon and opens the device when install is requested.
		12
		13	What: /sys/devices/platform/kim/baud_rate
		14	Date: January 2010
		15	KernelVersion: 2.6.38
		16	Contact: "Pavan Savoy" <pavan_savoy@ti.com>
		17	Description:
		18	The maximum reliable baud-rate the host can support.
		19	Different platforms tend to have different high-speed
		20	UART configurations, so the baud-rate needs to be set
		21	locally and also sent across to the WL128x via a HCI-VS
		22	command. The entry is read and made use by the user-space
		23	daemon when the ldisc install is requested.
		24
		25	What: /sys/devices/platform/kim/flow_cntrl
		26	Date: January 2010
		27	KernelVersion: 2.6.38
		28	Contact: "Pavan Savoy" <pavan_savoy@ti.com>
		29	Description:
		30	The WL128x makes use of flow control mechanism, and this
		31	entry most often should be 1, the host's UART is required
		32	to have the capability of flow-control, or else this
		33	entry can be made use of for exceptions.
		34
		35	What: /sys/devices/platform/kim/install
		36	Date: January 2010
		37	KernelVersion: 2.6.38
		38	Contact: "Pavan Savoy" <pavan_savoy@ti.com>
		39	Description:
		40	When one of the protocols Bluetooth, FM or GPS wants to make
		41	use of the shared UART transport, it registers to the shared
		42	transport driver, which will signal the user-space for opening,
		43	configuring baud and install line discipline via this sysfs
		44	entry. This entry would be polled upon by the user-space
		45	daemon managing the UART, and is notified about the change
		46	by the sysfs_notify. The value would be '1' when UART needs
		47	to be opened/ldisc installed, and would be '0' when UART
		48	is no more required and needs to be closed.