-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'origin' into spi/next
Pull in Linus' tree to pick up changes required for the langwell gpio fixes
- Loading branch information
Showing
4,523 changed files
with
312,108 additions
and
178,934 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| Where: /dev/pstore/... | ||
| Date: January 2011 | ||
| Kernel Version: 2.6.38 | ||
| Contact: tony.luck@intel.com | ||
| Description: Generic interface to platform dependent persistent storage. | ||
|
|
||
| Platforms that provide a mechanism to preserve some data | ||
| across system reboots can register with this driver to | ||
| provide a generic interface to show records captured in | ||
| the dying moments. In the case of a panic the last part | ||
| of the console log is captured, but other interesting | ||
| data can also be saved. | ||
|
|
||
| # mount -t pstore - /dev/pstore | ||
|
|
||
| $ ls -l /dev/pstore | ||
| total 0 | ||
| -r--r--r-- 1 root root 7896 Nov 30 15:38 dmesg-erst-1 | ||
|
|
||
| Different users of this interface will result in different | ||
| filename prefixes. Currently two are defined: | ||
|
|
||
| "dmesg" - saved console log | ||
| "mce" - architecture dependent data from fatal h/w error | ||
|
|
||
| Once the information in a file has been read, removing | ||
| the file will signal to the underlying persistent storage | ||
| device that it can reclaim the space for later re-use. | ||
|
|
||
| $ rm /dev/pstore/dmesg-erst-1 | ||
|
|
||
| The expectation is that all files in /dev/pstore | ||
| will be saved elsewhere and erased from persistent store | ||
| soon after boot to free up space ready for the next | ||
| catastrophe. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| What: /sys/fs/pstore/kmsg_bytes | ||
| Date: January 2011 | ||
| Kernel Version: 2.6.38 | ||
| Contact: "Tony Luck" <tony.luck@intel.com> | ||
| Description: | ||
| Controls amount of console log that will be saved | ||
| to persistent store on oops/panic. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.