kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/drivers/firmware/dmi-sysfs.c

697 lines
17 KiB
Raw Permalink Normal View History

firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap() for RAM mappings The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function should be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations being mapped decrypted vs encrypted. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Young <dyoung@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Larry Woodman <lwoodman@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Toshimitsu Kani <toshi.kani@hpe.com> Cc: kasan-dev@googlegroups.com Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/b13fccb9abbd547a7eef7b1fdfc223431b211c88.1500319216.git.thomas.lendacky@amd.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-17 16:10:00 -05:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: Break out system_event_log in dmi-sysfs 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-22 17:53:26 -08:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: Break out system_event_log in dmi-sysfs 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-22 17:53:26 -08:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: Break out system_event_log in dmi-sysfs 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-22 17:53:26 -08:00
firmware: Fix unaligned memory accesses in dmi-sysfs 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-25 15:41:49 -08:00
firmware: Break out system_event_log in dmi-sysfs 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-22 17:53:26 -08:00
firmware: Fix unaligned memory accesses in dmi-sysfs 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-25 15:41:49 -08:00
firmware: Break out system_event_log in dmi-sysfs 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-22 17:53:26 -08:00
firmware: Expose DMI type 15 System Event Log 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-22 17:53:31 -08:00
x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap() for RAM mappings The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function should be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations being mapped decrypted vs encrypted. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Young <dyoung@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Larry Woodman <lwoodman@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Toshimitsu Kani <toshi.kani@hpe.com> Cc: kasan-dev@googlegroups.com Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/b13fccb9abbd547a7eef7b1fdfc223431b211c88.1500319216.git.thomas.lendacky@amd.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-17 16:10:00 -05:00
firmware: Expose DMI type 15 System Event Log 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-22 17:53:31 -08:00
x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap() for RAM mappings The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function should be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations being mapped decrypted vs encrypted. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Young <dyoung@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Larry Woodman <lwoodman@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Toshimitsu Kani <toshi.kani@hpe.com> Cc: kasan-dev@googlegroups.com Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/b13fccb9abbd547a7eef7b1fdfc223431b211c88.1500319216.git.thomas.lendacky@amd.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-17 16:10:00 -05:00
firmware: Expose DMI type 15 System Event Log 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-22 17:53:31 -08:00
firmware: Fix unaligned memory accesses in dmi-sysfs 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-25 15:41:49 -08:00
firmware: Expose DMI type 15 System Event Log 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-22 17:53:31 -08:00
firmware: Fix unaligned memory accesses in dmi-sysfs 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-25 15:41:49 -08:00
firmware: Expose DMI type 15 System Event Log 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-22 17:53:31 -08:00
firmware: Fix unaligned memory accesses in dmi-sysfs 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-25 15:41:49 -08:00
firmware: Expose DMI type 15 System Event Log 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-22 17:53:31 -08:00
firmware: Fix unaligned memory accesses in dmi-sysfs 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-25 15:41:49 -08:00
firmware: Expose DMI type 15 System Event Log 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-22 17:53:31 -08:00
firmware: Fix unaligned memory accesses in dmi-sysfs 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-25 15:41:49 -08:00
firmware: Expose DMI type 15 System Event Log 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-22 17:53:31 -08:00
firmware: Fix unaligned memory accesses in dmi-sysfs 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-25 15:41:49 -08:00
firmware: Expose DMI type 15 System Event Log 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-22 17:53:31 -08:00
firmware: Break out system_event_log in dmi-sysfs 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-22 17:53:26 -08:00
firmware: Expose DMI type 15 System Event Log 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-22 17:53:31 -08:00
firmware: Break out system_event_log in dmi-sysfs 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-22 17:53:26 -08:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: dmi-sysfs: Don't remove dmi-sysfs "raw" file explicitly 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>
2013-12-05 16:46:28 -07:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: Fix unaligned memory accesses in dmi-sysfs 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-25 15:41:49 -08:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: Break out system_event_log in dmi-sysfs 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-22 17:53:26 -08:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: Break out system_event_log in dmi-sysfs 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-22 17:53:26 -08:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: Break out system_event_log in dmi-sysfs 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-22 17:53:26 -08:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: dmi_scan: add SBMIOS entry and DMI tables 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>
2015-06-25 09:06:56 +02:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: dmi_scan: add SBMIOS entry and DMI tables 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>
2015-06-25 09:06:56 +02:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: dmi_scan: add SBMIOS entry and DMI tables 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>
2015-06-25 09:06:56 +02:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: dmi_scan: add SBMIOS entry and DMI tables 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>
2015-06-25 09:06:56 +02:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00
firmware: dmi_scan: add SBMIOS entry and DMI tables 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>
2015-06-25 09:06:56 +02:00
firmware: Basic dmi-sysfs support 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>
2011-02-22 17:53:21 -08:00