09 Dec, 2013

2 commits

  • 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
    Signed-off-by: Greg Kroah-Hartman

    Bjorn 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
    Signed-off-by: Greg Kroah-Hartman

    Bjorn Helgaas
     

26 Feb, 2011

4 commits

  • 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
    Tested-by: Tony Luck
    Signed-off-by: Greg Kroah-Hartman

    Mike 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
    Signed-off-by: Greg Kroah-Hartman

    Mike 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
    Signed-off-by: Greg Kroah-Hartman

    Mike 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 "-", where:
    : is the type of the entry, and
    : 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
    Signed-off-by: Greg Kroah-Hartman

    Mike Waychison