Fix the grammar in describing the position attribute of DMI entries in the dmi-sysfs module. While here, make a couple other small clarifying fixups to the docs. Reported-by: <Valdis.Kletnieks@vt.edu> Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
		
			
				
	
	
		
			110 lines
		
	
	
	
		
			4 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			110 lines
		
	
	
	
		
			4 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
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 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 experiences 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 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.  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 entry's 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.
 |