summaryrefslogtreecommitdiffstats
path: root/drivers/firmware/dmi-sysfs.c
Commit message (Collapse)AuthorAgeFilesLines
* firmware: Fix unaligned memory accesses in dmi-sysfsMike Waychison2011-02-251-15/+13
| | | | | | | | | | | | | | | DMI entries are arranged in memory back to back with no alignment guarantees. This means that the struct dmi_header passed to callbacks from dmi_walk() itself isn't byte aligned. This causes problems on architectures that expect aligned data, such as IA64. The dmi-sysfs patchset introduced structure member accesses through this passed in dmi_header. Fix this by memcpy()ing the structures to temporary locations on stack when inspecting/copying them. Signed-off-by: Mike Waychison <mikew@google.com> Tested-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* firmware: Expose DMI type 15 System Event LogMike Waychison2011-02-251-0/+143
| | | | | | | | | | | | | | | | | The System Event Log described by DMI entry type 15 may be backed by either memory or may be indirectly accessed via an IO index/data register pair. In order to get read access to this log, expose it in the "system_event_log" sub-directory of type 15 DMI entries, ie: /sys/firmware/dmi/entries/15-0/system_event_log/raw_event_log. This commit handles both IO accessed and memory access system event logs. OEM specific access and GPNV support is explicitly not handled and we error out in the logs when we do not recognize the access method. Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* firmware: Break out system_event_log in dmi-sysfsMike Waychison2011-02-251-0/+159
| | | | | | | | | | | | | | | | | The optional type 15 entry of the DMI table describes a non-volatile storage-backed system event log. In preparation for the next commit which exposes the raw bits of the event log to userland, create a new sub-directory within the dmi entry called "system_event_log" and expose attribute files that describe the event log itself. Currently, only a single child object is permitted within a dmi_sysfs_entry. We simply point at this child from the dmi_sysfs_entry if it exists. Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* firmware: Basic dmi-sysfs supportMike Waychison2011-02-251-0/+396
Introduce a new module "dmi-sysfs" that exports the broken out entries of the DMI table through sysfs. Entries are enumerated via dmi_walk() on module load, and are populated as kobjects rooted at /sys/firmware/dmi/entries. Entries are named "<type>-<instance>", where: <type> : is the type of the entry, and <instance> : is the ordinal count within the DMI table of that entry type. This instance is used in lieu the DMI entry's handle as no assurances are made by the kernel that handles are unique. All entries export the following attributes: length : The length of the formatted portion of the entry handle : The handle given to this entry by the firmware raw : The raw bytes of the entire entry, including the formatted portion, the unformatted (strings) portion, and the two terminating nul characters. type : The DMI entry type instance : The ordinal instance of this entry given its type. position : The position ordinal of the entry within the table in its entirety. Entries in dmi-sysfs are kobject backed members called "struct dmi_sysfs_entry" and belong to dmi_kset. They are threaded through entry_list (protected by entry_list_lock) so that we can find them at cleanup time. Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>