Loading Documentation/00-INDEX +0 −2 Original line number Diff line number Diff line Loading @@ -328,8 +328,6 @@ sysrq.txt - info on the magic SysRq key. telephony/ - directory with info on telephony (e.g. voice over IP) support. uml/ - directory with information about User Mode Linux. unicode.txt - info on the Unicode character/font mapping used in Linux. unshare.txt Loading Documentation/ABI/testing/sysfs-bus-bcma 0 → 100644 +31 −0 Original line number Diff line number Diff line What: /sys/bus/bcma/devices/.../manuf Date: May 2011 KernelVersion: 2.6.40 Contact: Rafał Miłecki <zajec5@gmail.com> Description: Each BCMA core has it's manufacturer id. See include/linux/bcma/bcma.h for possible values. What: /sys/bus/bcma/devices/.../id Date: May 2011 KernelVersion: 2.6.40 Contact: Rafał Miłecki <zajec5@gmail.com> Description: There are a few types of BCMA cores, they can be identified by id field. What: /sys/bus/bcma/devices/.../rev Date: May 2011 KernelVersion: 2.6.40 Contact: Rafał Miłecki <zajec5@gmail.com> Description: BCMA cores of the same type can still slightly differ depending on their revision. Use it for detailed programming. What: /sys/bus/bcma/devices/.../class Date: May 2011 KernelVersion: 2.6.40 Contact: Rafał Miłecki <zajec5@gmail.com> Description: Each BCMA core is identified by few fields, including class it belongs to. See include/linux/bcma/bcma.h for possible values. Documentation/ABI/testing/sysfs-devices-system-cpu +17 −17 Original line number Diff line number Diff line Loading @@ -183,21 +183,21 @@ Description: Discover and change clock speed of CPUs to learn how to control the knobs. What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1} Date: August 2008 KernelVersion: 2.6.27 Contact: mark.langsdorf@amd.com Description: These files exist in every cpu's cache index directories. There are currently 2 cache_disable_# files in each directory. Reading from these files on a supported processor will return that cache disable index value for that processor and node. Writing to one of these files will cause the specificed cache index to be disabled. Currently, only AMD Family 10h Processors support cache index disable, and only for their L3 caches. See the BIOS and Kernel Developer's Guide at http://support.amd.com/us/Embedded_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf for formatting information and other details on the cache index disable. Users: joachim.deguara@amd.com Contact: discuss@x86-64.org Description: Disable L3 cache indices These files exist in every CPU's cache/index3 directory. Each cache_disable_{0,1} file corresponds to one disable slot which can be used to disable a cache index. Reading from these files on a processor with this functionality will return the currently disabled index for that node. There is one L3 structure per node, or per internal node on MCM machines. Writing a valid index to one of these files will cause the specificed cache index to be disabled. All AMD processors with L3 caches provide this functionality. For details, see BKDGs at http://developer.amd.com/documentation/guides/Pages/default.aspx Documentation/ABI/testing/sysfs-firmware-dmi +9 −9 Original line number Diff line number Diff line Loading @@ -14,14 +14,15 @@ Description: 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. length of the entry, as well as a firmware-provided '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. is doing. Machine to machine experiences will vary. Multiple entries of the same type are allowed. In order to handle these duplicate entry types, each entry is Loading Loading @@ -67,25 +68,24 @@ Description: 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. 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. position: The ordinal position (zero-based) of the entry within the entirety of the DMI entry table. === Entry Specialization === Some entry types may have other information available in sysfs. sysfs. Not all types are specialized. --- 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 details are abstracted by this table. This entry's data is exported in the directory: /sys/firmware/dmi/entries/15-0/system_event_log Loading Documentation/ABI/testing/sysfs-firmware-gsmi 0 → 100644 +58 −0 Original line number Diff line number Diff line What: /sys/firmware/gsmi Date: March 2011 Contact: Mike Waychison <mikew@google.com> Description: Some servers used internally at Google have firmware that provides callback functionality via explicit SMI triggers. Some of the callbacks are similar to those provided by the EFI runtime services page, but due to historical reasons this different entry-point has been used. The gsmi driver implements the kernel's abstraction for these firmware callbacks. Currently, this functionality is limited to handling the system event log and getting access to EFI-style variables stored in nvram. Layout: /sys/firmware/gsmi/vars: This directory has the same layout (and underlying implementation as /sys/firmware/efi/vars. See Documentation/ABI/*/sysfs-firmware-efi-vars for more information on how to interact with this structure. /sys/firmware/gsmi/append_to_eventlog - write-only: This file takes a binary blob and passes it onto the firmware to be timestamped and appended to the system eventlog. The binary format is interpreted by the firmware and may change from platform to platform. The only kernel-enforced requirement is that the blob be prefixed with a 32bit host-endian type used as part of the firmware call. /sys/firmware/gsmi/clear_config - write-only: Writing any value to this file will cause the entire firmware configuration to be reset to "factory defaults". Callers should assume that a reboot is required for the configuration to be cleared. /sys/firmware/gsmi/clear_eventlog - write-only: This file is used to clear out a portion/the whole of the system event log. Values written should be values between 1 and 100 inclusive (in ASCII) representing the fraction of the log to clear. Not all platforms support fractional clearing though, and this writes to this file will error out if the firmware doesn't like your submitted fraction. Callers should assume that a reboot is needed for this operation to complete. Loading
Documentation/00-INDEX +0 −2 Original line number Diff line number Diff line Loading @@ -328,8 +328,6 @@ sysrq.txt - info on the magic SysRq key. telephony/ - directory with info on telephony (e.g. voice over IP) support. uml/ - directory with information about User Mode Linux. unicode.txt - info on the Unicode character/font mapping used in Linux. unshare.txt Loading
Documentation/ABI/testing/sysfs-bus-bcma 0 → 100644 +31 −0 Original line number Diff line number Diff line What: /sys/bus/bcma/devices/.../manuf Date: May 2011 KernelVersion: 2.6.40 Contact: Rafał Miłecki <zajec5@gmail.com> Description: Each BCMA core has it's manufacturer id. See include/linux/bcma/bcma.h for possible values. What: /sys/bus/bcma/devices/.../id Date: May 2011 KernelVersion: 2.6.40 Contact: Rafał Miłecki <zajec5@gmail.com> Description: There are a few types of BCMA cores, they can be identified by id field. What: /sys/bus/bcma/devices/.../rev Date: May 2011 KernelVersion: 2.6.40 Contact: Rafał Miłecki <zajec5@gmail.com> Description: BCMA cores of the same type can still slightly differ depending on their revision. Use it for detailed programming. What: /sys/bus/bcma/devices/.../class Date: May 2011 KernelVersion: 2.6.40 Contact: Rafał Miłecki <zajec5@gmail.com> Description: Each BCMA core is identified by few fields, including class it belongs to. See include/linux/bcma/bcma.h for possible values.
Documentation/ABI/testing/sysfs-devices-system-cpu +17 −17 Original line number Diff line number Diff line Loading @@ -183,21 +183,21 @@ Description: Discover and change clock speed of CPUs to learn how to control the knobs. What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1} Date: August 2008 KernelVersion: 2.6.27 Contact: mark.langsdorf@amd.com Description: These files exist in every cpu's cache index directories. There are currently 2 cache_disable_# files in each directory. Reading from these files on a supported processor will return that cache disable index value for that processor and node. Writing to one of these files will cause the specificed cache index to be disabled. Currently, only AMD Family 10h Processors support cache index disable, and only for their L3 caches. See the BIOS and Kernel Developer's Guide at http://support.amd.com/us/Embedded_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf for formatting information and other details on the cache index disable. Users: joachim.deguara@amd.com Contact: discuss@x86-64.org Description: Disable L3 cache indices These files exist in every CPU's cache/index3 directory. Each cache_disable_{0,1} file corresponds to one disable slot which can be used to disable a cache index. Reading from these files on a processor with this functionality will return the currently disabled index for that node. There is one L3 structure per node, or per internal node on MCM machines. Writing a valid index to one of these files will cause the specificed cache index to be disabled. All AMD processors with L3 caches provide this functionality. For details, see BKDGs at http://developer.amd.com/documentation/guides/Pages/default.aspx
Documentation/ABI/testing/sysfs-firmware-dmi +9 −9 Original line number Diff line number Diff line Loading @@ -14,14 +14,15 @@ Description: 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. length of the entry, as well as a firmware-provided '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. is doing. Machine to machine experiences will vary. Multiple entries of the same type are allowed. In order to handle these duplicate entry types, each entry is Loading Loading @@ -67,25 +68,24 @@ Description: 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. 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. position: The ordinal position (zero-based) of the entry within the entirety of the DMI entry table. === Entry Specialization === Some entry types may have other information available in sysfs. sysfs. Not all types are specialized. --- 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 details are abstracted by this table. This entry's data is exported in the directory: /sys/firmware/dmi/entries/15-0/system_event_log Loading
Documentation/ABI/testing/sysfs-firmware-gsmi 0 → 100644 +58 −0 Original line number Diff line number Diff line What: /sys/firmware/gsmi Date: March 2011 Contact: Mike Waychison <mikew@google.com> Description: Some servers used internally at Google have firmware that provides callback functionality via explicit SMI triggers. Some of the callbacks are similar to those provided by the EFI runtime services page, but due to historical reasons this different entry-point has been used. The gsmi driver implements the kernel's abstraction for these firmware callbacks. Currently, this functionality is limited to handling the system event log and getting access to EFI-style variables stored in nvram. Layout: /sys/firmware/gsmi/vars: This directory has the same layout (and underlying implementation as /sys/firmware/efi/vars. See Documentation/ABI/*/sysfs-firmware-efi-vars for more information on how to interact with this structure. /sys/firmware/gsmi/append_to_eventlog - write-only: This file takes a binary blob and passes it onto the firmware to be timestamped and appended to the system eventlog. The binary format is interpreted by the firmware and may change from platform to platform. The only kernel-enforced requirement is that the blob be prefixed with a 32bit host-endian type used as part of the firmware call. /sys/firmware/gsmi/clear_config - write-only: Writing any value to this file will cause the entire firmware configuration to be reset to "factory defaults". Callers should assume that a reboot is required for the configuration to be cleared. /sys/firmware/gsmi/clear_eventlog - write-only: This file is used to clear out a portion/the whole of the system event log. Values written should be values between 1 and 100 inclusive (in ASCII) representing the fraction of the log to clear. Not all platforms support fractional clearing though, and this writes to this file will error out if the firmware doesn't like your submitted fraction. Callers should assume that a reboot is needed for this operation to complete.