summaryrefslogtreecommitdiff
path: root/drivers/firmware/dmi-sysfs.c
AgeCommit message (Collapse)Author
2015-06-25firmware: dmi_scan: add SBMIOS entry and DMI tablesIvan Khoronzhuk
Some utils, like dmidecode and smbios, need to access SMBIOS entry table area in order to get information like SMBIOS version, size, etc. Currently it's done via /dev/mem. But for situation when /dev/mem usage is disabled, the utils have to use dmi sysfs instead, which doesn't represent SMBIOS entry and adds code/delay redundancy when direct access for table is needed. So this patch creates dmi/tables and adds SMBIOS entry point to allow utils in question to work correctly without /dev/mem. Also patch adds raw dmi table to simplify dmi table processing in user space, as proposed by Jean Delvare. Tested-by: Roy Franz <roy.franz@linaro.org> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@globallogic.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
2013-12-08firmware: dmi-sysfs: Remove "dmi" directory on module exitBjorn Helgaas
With CONFIG_DEBUG_KOBJECT_RELEASE=y, removing and immediately reloading the dmi-sysfs module causes the following warning: sysfs: cannot create duplicate filename '/firmware/dmi' kobject_add_internal failed for dmi with -EEXIST, don't try to register things with the same name in the same directory. The "dmi" directory stays in sysfs until the dmi_kobj is released, and DEBUG_KOBJECT_RELEASE delays that. I don't think we can hit this problem in normal usage because dmi_kobj is static and nothing outside dmi-sysfs can get a reference to it, so the only way to delay the "dmi" release is with DEBUG_KOBJECT_RELEASE. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-08firmware: dmi-sysfs: Don't remove dmi-sysfs "raw" file explicitlyBjorn Helgaas
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: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2011-02-25firmware: Fix unaligned memory accesses in dmi-sysfsMike Waychison
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>
2011-02-25firmware: Expose DMI type 15 System Event LogMike Waychison
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>
2011-02-25firmware: Break out system_event_log in dmi-sysfsMike Waychison
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>
2011-02-25firmware: Basic dmi-sysfs supportMike Waychison
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>