Removing the dmi-sysfs module causes the following warning:

  # modprobe -r dmi_sysfs
  WARNING: CPU: 11 PID: 6785 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
  sysfs: can not remove 'raw', no directory

This is because putting the entry kobject, e.g., for
"/sys/firmware/dmi/entries/19-0", removes the directory and all its
contents.  By the time dmi_sysfs_entry_release() runs, the "raw" file
inside ".../19-0/" has already been removed.

Therefore, we don't need to remove the "raw" bin file at all in
dmi_sysfs_entry_release().
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NMike Waychison <mikew@google.com>
Tested-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>