From 17cd5bd5391e6e7b363d66335e1bc6760ae969b9 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 25 Jun 2015 09:06:55 +0200 Subject: firmware: dmi_scan: Only honor end-of-table for 64-bit tables A 32-bit entry point to a DMI table says how many structures the table contains. The SMBIOS specification explicitly says that end-of-table markers should be ignored if they are not actually at the end of the DMI table. So only honor the end-of-table marker for tables accessed through 64-bit entry points, as they do not specify a structure count. Fixes: fc43026278 ("dmi: add support for SMBIOS 3.0 64-bit entry point") Signed-off-by: Jean Delvare Acked-by: Ard Biesheuvel Cc: Leif Lindholm Cc: Matt Fleming diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c index 97b1616..bba843c 100644 --- a/drivers/firmware/dmi_scan.c +++ b/drivers/firmware/dmi_scan.c @@ -89,9 +89,9 @@ static void dmi_table(u8 *buf, /* * Stop when we have seen all the items the table claimed to have - * (SMBIOS < 3.0 only) OR we reach an end-of-table marker OR we run - * off the end of the table (should never happen but sometimes does - * on bogus implementations.) + * (SMBIOS < 3.0 only) OR we reach an end-of-table marker (SMBIOS + * >= 3.0 only) OR we run off the end of the table (should never + * happen but sometimes does on bogus implementations.) */ while ((!dmi_num || i < dmi_num) && (data - buf + sizeof(struct dmi_header)) <= dmi_len) { @@ -110,8 +110,13 @@ static void dmi_table(u8 *buf, /* * 7.45 End-of-Table (Type 127) [SMBIOS reference spec v3.0.0] + * For tables behind a 64-bit entry point, we have no item + * count and no exact table length, so stop on end-of-table + * marker. For tables behind a 32-bit entry point, we have + * seen OEM structures behind the end-of-table marker on + * some systems, so don't trust it. */ - if (dm->type == DMI_ENTRY_END_OF_TABLE) + if (!dmi_num && dm->type == DMI_ENTRY_END_OF_TABLE) break; data += 2; -- cgit v0.10.2 From d4aeef932345ce95a56fb487531e86f1cbd7150d Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 25 Jun 2015 09:06:56 +0200 Subject: firmware: dmi: List my quilt tree I'll be maintaining the pending patches to the dmi_scan and dmi-id drivers as a quilt tree. Signed-off-by: Jean Delvare diff --git a/MAINTAINERS b/MAINTAINERS index d8afd29..0502f9a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3288,6 +3288,7 @@ F: drivers/hwmon/dme1737.c DMI/SMBIOS SUPPORT M: Jean Delvare S: Maintained +T: quilt http://jdelvare.nerim.net/devel/linux/jdelvare-dmi/ F: drivers/firmware/dmi-id.c F: drivers/firmware/dmi_scan.c F: include/linux/dmi.h -- cgit v0.10.2 From eb4c5ea50e60aa8faaf6aae762cb06ee1c8e0b8e Mon Sep 17 00:00:00 2001 From: Ivan Khoronzhuk Date: Thu, 25 Jun 2015 09:06:56 +0200 Subject: firmware: dmi_scan: Rename dmi_table to dmi_decode_table The "dmi_table" function looks like data instance, but it does DMI table decode. This patch renames it to "dmi_decode_table" name as more appropriate. That allows us to use "dmi_table" name for correct purposes. Signed-off-by: Ivan Khoronzhuk Signed-off-by: Jean Delvare diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c index bba843c..14a8912 100644 --- a/drivers/firmware/dmi_scan.c +++ b/drivers/firmware/dmi_scan.c @@ -80,9 +80,9 @@ static const char * __init dmi_string(const struct dmi_header *dm, u8 s) * We have to be cautious here. We have seen BIOSes with DMI pointers * pointing to completely the wrong place for example */ -static void dmi_table(u8 *buf, - void (*decode)(const struct dmi_header *, void *), - void *private_data) +static void dmi_decode_table(u8 *buf, + void (*decode)(const struct dmi_header *, void *), + void *private_data) { u8 *data = buf; int i = 0; @@ -135,7 +135,7 @@ static int __init dmi_walk_early(void (*decode)(const struct dmi_header *, if (buf == NULL) return -1; - dmi_table(buf, decode, NULL); + dmi_decode_table(buf, decode, NULL); add_device_randomness(buf, dmi_len); @@ -902,7 +902,7 @@ int dmi_walk(void (*decode)(const struct dmi_header *, void *), if (buf == NULL) return -1; - dmi_table(buf, decode, private_data); + dmi_decode_table(buf, decode, private_data); dmi_unmap(buf); return 0; -- cgit v0.10.2 From 6e0ad59e3d838a2887e7aa657baee5896030d009 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 25 Jun 2015 09:06:56 +0200 Subject: firmware: dmi_scan: Trim DMI table length before exporting it The SMBIOS v3 entry points specify a maximum length for the DMI table, not the exact length. Thus there may be garbage after the end-of-table marker, which we don't want to export to user-space. Adjust dmi_len when we find the end-of-table marker, so that only the actual table payload is exported. Signed-off-by: Jean Delvare Cc: Ivan Khoronzhuk diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c index 14a8912..7fdf286 100644 --- a/drivers/firmware/dmi_scan.c +++ b/drivers/firmware/dmi_scan.c @@ -108,6 +108,9 @@ static void dmi_decode_table(u8 *buf, if (data - buf < dmi_len - 1) decode(dm, private_data); + data += 2; + i++; + /* * 7.45 End-of-Table (Type 127) [SMBIOS reference spec v3.0.0] * For tables behind a 64-bit entry point, we have no item @@ -118,10 +121,11 @@ static void dmi_decode_table(u8 *buf, */ if (!dmi_num && dm->type == DMI_ENTRY_END_OF_TABLE) break; - - data += 2; - i++; } + + /* Trim DMI table length if needed */ + if (dmi_len > data - buf) + dmi_len = data - buf; } static phys_addr_t dmi_base; @@ -130,8 +134,9 @@ static int __init dmi_walk_early(void (*decode)(const struct dmi_header *, void *)) { u8 *buf; + u32 orig_dmi_len = dmi_len; - buf = dmi_early_remap(dmi_base, dmi_len); + buf = dmi_early_remap(dmi_base, orig_dmi_len); if (buf == NULL) return -1; @@ -139,7 +144,7 @@ static int __init dmi_walk_early(void (*decode)(const struct dmi_header *, add_device_randomness(buf, dmi_len); - dmi_early_unmap(buf, dmi_len); + dmi_early_unmap(buf, orig_dmi_len); return 0; } -- cgit v0.10.2 From d7f96f97c4031fa4ffdb7801f9aae23e96170a6f Mon Sep 17 00:00:00 2001 From: Ivan Khoronzhuk Date: Thu, 25 Jun 2015 09:06:56 +0200 Subject: 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 Signed-off-by: Ivan Khoronzhuk Signed-off-by: Jean Delvare diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables b/Documentation/ABI/testing/sysfs-firmware-dmi-tables new file mode 100644 index 0000000..ff3cac8 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables @@ -0,0 +1,22 @@ +What: /sys/firmware/dmi/tables/ +Date: April 2015 +Contact: Ivan Khoronzhuk +Description: + The firmware provides DMI structures as a packed list of + data referenced by a SMBIOS table entry point. The SMBIOS + entry point contains general information, like SMBIOS + version, DMI table size, etc. The structure, content and + size of SMBIOS entry point is dependent on SMBIOS version. + The format of SMBIOS entry point and DMI structures + can be read in SMBIOS specification. + + The dmi/tables provides raw SMBIOS entry point and DMI tables + through sysfs as an alternative to utilities reading them + from /dev/mem. The raw SMBIOS entry point and DMI table are + presented as binary attributes and are accessible via: + + /sys/firmware/dmi/tables/smbios_entry_point + /sys/firmware/dmi/tables/DMI + + The complete DMI information can be obtained using these two + tables. diff --git a/MAINTAINERS b/MAINTAINERS index 0502f9a..ca47368 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3289,6 +3289,7 @@ DMI/SMBIOS SUPPORT M: Jean Delvare S: Maintained T: quilt http://jdelvare.nerim.net/devel/linux/jdelvare-dmi/ +F: Documentation/ABI/testing/sysfs-firmware-dmi-tables F: drivers/firmware/dmi-id.c F: drivers/firmware/dmi_scan.c F: include/linux/dmi.h diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c index e0f1cb3..ef76e5e 100644 --- a/drivers/firmware/dmi-sysfs.c +++ b/drivers/firmware/dmi-sysfs.c @@ -566,7 +566,6 @@ static struct kobj_type dmi_sysfs_entry_ktype = { .default_attrs = dmi_sysfs_entry_attrs, }; -static struct kobject *dmi_kobj; static struct kset *dmi_kset; /* Global count of all instances seen. Only for setup */ @@ -648,17 +647,20 @@ static void cleanup_entry_list(void) static int __init dmi_sysfs_init(void) { - int error = -ENOMEM; + int error; int val; - /* Set up our directory */ - dmi_kobj = kobject_create_and_add("dmi", firmware_kobj); - if (!dmi_kobj) + if (!dmi_kobj) { + pr_err("dmi-sysfs: dmi entry is absent.\n"); + error = -ENODATA; goto err; + } dmi_kset = kset_create_and_add("entries", NULL, dmi_kobj); - if (!dmi_kset) + if (!dmi_kset) { + error = -ENOMEM; goto err; + } val = 0; error = dmi_walk(dmi_sysfs_register_handle, &val); @@ -675,7 +677,6 @@ static int __init dmi_sysfs_init(void) err: cleanup_entry_list(); kset_unregister(dmi_kset); - kobject_put(dmi_kobj); return error; } @@ -685,8 +686,6 @@ static void __exit dmi_sysfs_exit(void) pr_debug("dmi-sysfs: unloading.\n"); cleanup_entry_list(); kset_unregister(dmi_kset); - kobject_del(dmi_kobj); - kobject_put(dmi_kobj); } module_init(dmi_sysfs_init); diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c index 7fdf286..5e0b770 100644 --- a/drivers/firmware/dmi_scan.c +++ b/drivers/firmware/dmi_scan.c @@ -10,6 +10,9 @@ #include #include +struct kobject *dmi_kobj; +EXPORT_SYMBOL_GPL(dmi_kobj); + /* * DMI stands for "Desktop Management Interface". It is part * of and an antecedent to, SMBIOS, which stands for System @@ -20,6 +23,9 @@ static const char dmi_empty_string[] = " "; static u32 dmi_ver __initdata; static u32 dmi_len; static u16 dmi_num; +static u8 smbios_entry_point[32]; +static int smbios_entry_point_size; + /* * Catch too early calls to dmi_check_system(): */ @@ -488,6 +494,8 @@ static int __init dmi_present(const u8 *buf) if (memcmp(buf, "_SM_", 4) == 0 && buf[5] < 32 && dmi_checksum(buf, buf[5])) { smbios_ver = get_unaligned_be16(buf + 6); + smbios_entry_point_size = buf[5]; + memcpy(smbios_entry_point, buf, smbios_entry_point_size); /* Some BIOS report weird SMBIOS version, fix that up */ switch (smbios_ver) { @@ -522,6 +530,9 @@ static int __init dmi_present(const u8 *buf) pr_info("SMBIOS %d.%d present.\n", dmi_ver >> 8, dmi_ver & 0xFF); } else { + smbios_entry_point_size = 15; + memcpy(smbios_entry_point, buf, + smbios_entry_point_size); pr_info("Legacy DMI %d.%d present.\n", dmi_ver >> 8, dmi_ver & 0xFF); } @@ -548,6 +559,8 @@ static int __init dmi_smbios3_present(const u8 *buf) dmi_num = 0; /* No longer specified */ dmi_len = get_unaligned_le32(buf + 12); dmi_base = get_unaligned_le64(buf + 16); + smbios_entry_point_size = buf[6]; + memcpy(smbios_entry_point, buf, smbios_entry_point_size); if (dmi_walk_early(dmi_decode) == 0) { pr_info("SMBIOS %d.%d.%d present.\n", @@ -639,6 +652,71 @@ void __init dmi_scan_machine(void) dmi_initialized = 1; } +static ssize_t raw_table_read(struct file *file, struct kobject *kobj, + struct bin_attribute *attr, char *buf, + loff_t pos, size_t count) +{ + memcpy(buf, attr->private + pos, count); + return count; +} + +static BIN_ATTR(smbios_entry_point, S_IRUSR, raw_table_read, NULL, 0); +static BIN_ATTR(DMI, S_IRUSR, raw_table_read, NULL, 0); + +static int __init dmi_init(void) +{ + struct kobject *tables_kobj; + u8 *dmi_table; + int ret = -ENOMEM; + + if (!dmi_available) { + ret = -ENODATA; + goto err; + } + + /* + * Set up dmi directory at /sys/firmware/dmi. This entry should stay + * even after farther error, as it can be used by other modules like + * dmi-sysfs. + */ + dmi_kobj = kobject_create_and_add("dmi", firmware_kobj); + if (!dmi_kobj) + goto err; + + tables_kobj = kobject_create_and_add("tables", dmi_kobj); + if (!tables_kobj) + goto err; + + dmi_table = dmi_remap(dmi_base, dmi_len); + if (!dmi_table) + goto err_tables; + + bin_attr_smbios_entry_point.size = smbios_entry_point_size; + bin_attr_smbios_entry_point.private = smbios_entry_point; + ret = sysfs_create_bin_file(tables_kobj, &bin_attr_smbios_entry_point); + if (ret) + goto err_unmap; + + bin_attr_DMI.size = dmi_len; + bin_attr_DMI.private = dmi_table; + ret = sysfs_create_bin_file(tables_kobj, &bin_attr_DMI); + if (!ret) + return 0; + + sysfs_remove_bin_file(tables_kobj, + &bin_attr_smbios_entry_point); + err_unmap: + dmi_unmap(dmi_table); + err_tables: + kobject_del(tables_kobj); + kobject_put(tables_kobj); + err: + pr_err("dmi: Firmware registration failed.\n"); + + return ret; +} +subsys_initcall(dmi_init); + /** * dmi_set_dump_stack_arch_desc - set arch description for dump_stack() * diff --git a/include/linux/dmi.h b/include/linux/dmi.h index f820f0a..2f9f988 100644 --- a/include/linux/dmi.h +++ b/include/linux/dmi.h @@ -2,6 +2,7 @@ #define __DMI_H__ #include +#include #include /* enum dmi_field is in mod_devicetable.h */ @@ -93,6 +94,7 @@ struct dmi_dev_onboard { int devfn; }; +extern struct kobject *dmi_kobj; extern int dmi_check_system(const struct dmi_system_id *list); const struct dmi_system_id *dmi_first_match(const struct dmi_system_id *list); extern const char * dmi_get_system_info(int field); -- cgit v0.10.2 From 863ef5ba29529165279562820cd7e6ea0a4f5793 Mon Sep 17 00:00:00 2001 From: Ivan Khoronzhuk Date: Thu, 25 Jun 2015 09:06:57 +0200 Subject: Documentation: ABI: sysfs-firmware-dmi: add -entries suffix to file name The dmi-sysfs module adds DMI table structures entries under /sys/firmware/dmi/entries only, so rename documentation file to sysfs-firmware-dmi-entries as more appropriate. Without renaming it's confusing to differ this from sysfs-firmware-dmi-tables that adds raw DMI table and actually adds "dmi" kobject. Signed-off-by: Ivan Khoronzhuk Signed-off-by: Jean Delvare diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi b/Documentation/ABI/testing/sysfs-firmware-dmi deleted file mode 100644 index c78f9ab..0000000 --- a/Documentation/ABI/testing/sysfs-firmware-dmi +++ /dev/null @@ -1,110 +0,0 @@ -What: /sys/firmware/dmi/ -Date: February 2011 -Contact: Mike Waychison -Description: - Many machines' firmware (x86 and ia64) export DMI / - SMBIOS tables to the operating system. Getting at this - information is often valuable to userland, especially in - cases where there are OEM extensions used. - - The kernel itself does not rely on the majority of the - information in these tables being correct. It equally - cannot ensure that the data as exported to userland is - without error either. - - DMI is structured as a large table of entries, where - each entry has a common header indicating the type and - length of the entry, as well as a firmware-provided - 'handle' that is supposed to be unique amongst all - entries. - - Some entries are required by the specification, but many - others are optional. In general though, users should - never expect to find a specific entry type on their - system unless they know for certain what their firmware - is doing. Machine to machine experiences will vary. - - Multiple entries of the same type are allowed. In order - to handle these duplicate entry types, each entry is - assigned by the operating system an 'instance', which is - derived from an entry type's ordinal position. That is - to say, if there are 'N' multiple entries with the same type - 'T' in the DMI tables (adjacent or spread apart, it - doesn't matter), they will be represented in sysfs as - entries "T-0" through "T-(N-1)": - - Example entry directories: - - /sys/firmware/dmi/entries/17-0 - /sys/firmware/dmi/entries/17-1 - /sys/firmware/dmi/entries/17-2 - /sys/firmware/dmi/entries/17-3 - ... - - Instance numbers are used in lieu of the firmware - assigned entry handles as the kernel itself makes no - guarantees that handles as exported are unique, and - there are likely firmware images that get this wrong in - the wild. - - Each DMI entry in sysfs has the common header values - exported as attributes: - - handle : The 16bit 'handle' that is assigned to this - entry by the firmware. This handle may be - referred to by other entries. - length : The length of the entry, as presented in the - entry itself. Note that this is _not the - total count of bytes associated with the - entry_. This value represents the length of - the "formatted" portion of the entry. This - "formatted" region is sometimes followed by - the "unformatted" region composed of nul - terminated strings, with termination signalled - by a two nul characters in series. - raw : The raw bytes of the entry. This includes the - "formatted" portion of the entry, the - "unformatted" strings portion of the entry, - and the two terminating nul characters. - type : The type of the entry. This value is the same - as found in the directory name. It indicates - how the rest of the entry should be interpreted. - instance: The instance ordinal of the entry for the - given type. This value is the same as found - in the parent directory name. - position: The ordinal position (zero-based) of the entry - within the entirety of the DMI entry table. - - === Entry Specialization === - - Some entry types may have other information available in - sysfs. Not all types are specialized. - - --- Type 15 - System Event Log --- - - This entry allows the firmware to export a log of - events the system has taken. This information is - typically backed by nvram, but the implementation - details are abstracted by this table. This entry's data - is exported in the directory: - - /sys/firmware/dmi/entries/15-0/system_event_log - - and has the following attributes (documented in the - SMBIOS / DMI specification under "System Event Log (Type 15)": - - area_length - header_start_offset - data_start_offset - access_method - status - change_token - access_method_address - header_format - per_log_type_descriptor_length - type_descriptors_supported_count - - As well, the kernel exports the binary attribute: - - raw_event_log : The raw binary bits of the event log - as described by the DMI entry. diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-entries b/Documentation/ABI/testing/sysfs-firmware-dmi-entries new file mode 100644 index 0000000..210ad44 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-dmi-entries @@ -0,0 +1,110 @@ +What: /sys/firmware/dmi/entries/ +Date: February 2011 +Contact: Mike Waychison +Description: + Many machines' firmware (x86 and ia64) export DMI / + SMBIOS tables to the operating system. Getting at this + information is often valuable to userland, especially in + cases where there are OEM extensions used. + + The kernel itself does not rely on the majority of the + information in these tables being correct. It equally + cannot ensure that the data as exported to userland is + without error either. + + DMI is structured as a large table of entries, where + each entry has a common header indicating the type and + length of the entry, as well as a firmware-provided + 'handle' that is supposed to be unique amongst all + entries. + + Some entries are required by the specification, but many + others are optional. In general though, users should + never expect to find a specific entry type on their + system unless they know for certain what their firmware + is doing. Machine to machine experiences will vary. + + Multiple entries of the same type are allowed. In order + to handle these duplicate entry types, each entry is + assigned by the operating system an 'instance', which is + derived from an entry type's ordinal position. That is + to say, if there are 'N' multiple entries with the same type + 'T' in the DMI tables (adjacent or spread apart, it + doesn't matter), they will be represented in sysfs as + entries "T-0" through "T-(N-1)": + + Example entry directories: + + /sys/firmware/dmi/entries/17-0 + /sys/firmware/dmi/entries/17-1 + /sys/firmware/dmi/entries/17-2 + /sys/firmware/dmi/entries/17-3 + ... + + Instance numbers are used in lieu of the firmware + assigned entry handles as the kernel itself makes no + guarantees that handles as exported are unique, and + there are likely firmware images that get this wrong in + the wild. + + Each DMI entry in sysfs has the common header values + exported as attributes: + + handle : The 16bit 'handle' that is assigned to this + entry by the firmware. This handle may be + referred to by other entries. + length : The length of the entry, as presented in the + entry itself. Note that this is _not the + total count of bytes associated with the + entry_. This value represents the length of + the "formatted" portion of the entry. This + "formatted" region is sometimes followed by + the "unformatted" region composed of nul + terminated strings, with termination signalled + by a two nul characters in series. + raw : The raw bytes of the entry. This includes the + "formatted" portion of the entry, the + "unformatted" strings portion of the entry, + and the two terminating nul characters. + type : The type of the entry. This value is the same + as found in the directory name. It indicates + how the rest of the entry should be interpreted. + instance: The instance ordinal of the entry for the + given type. This value is the same as found + in the parent directory name. + position: The ordinal position (zero-based) of the entry + within the entirety of the DMI entry table. + + === Entry Specialization === + + Some entry types may have other information available in + sysfs. Not all types are specialized. + + --- Type 15 - System Event Log --- + + This entry allows the firmware to export a log of + events the system has taken. This information is + typically backed by nvram, but the implementation + details are abstracted by this table. This entry's data + is exported in the directory: + + /sys/firmware/dmi/entries/15-0/system_event_log + + and has the following attributes (documented in the + SMBIOS / DMI specification under "System Event Log (Type 15)": + + area_length + header_start_offset + data_start_offset + access_method + status + change_token + access_method_address + header_format + per_log_type_descriptor_length + type_descriptors_supported_count + + As well, the kernel exports the binary attribute: + + raw_event_log : The raw binary bits of the event log + as described by the DMI entry. -- cgit v0.10.2 From d1d8704c48f9c2bb791e8e183a41019f35a3f7f0 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 25 Jun 2015 09:06:57 +0200 Subject: firmware: dmi_scan: Coding style cleanups Signed-off-by: Jean Delvare diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c index 5e0b770..ac1ce4a 100644 --- a/drivers/firmware/dmi_scan.c +++ b/drivers/firmware/dmi_scan.c @@ -501,12 +501,12 @@ static int __init dmi_present(const u8 *buf) switch (smbios_ver) { case 0x021F: case 0x0221: - pr_debug("SMBIOS version fixup(2.%d->2.%d)\n", + pr_debug("SMBIOS version fixup (2.%d->2.%d)\n", smbios_ver & 0xFF, 3); smbios_ver = 0x0203; break; case 0x0233: - pr_debug("SMBIOS version fixup(2.%d->2.%d)\n", 51, 6); + pr_debug("SMBIOS version fixup (2.%d->2.%d)\n", 51, 6); smbios_ver = 0x0206; break; } @@ -554,8 +554,7 @@ static int __init dmi_smbios3_present(const u8 *buf) { if (memcmp(buf, "_SM3_", 5) == 0 && buf[6] < 32 && dmi_checksum(buf, buf[6])) { - dmi_ver = get_unaligned_be32(buf + 6); - dmi_ver &= 0xFFFFFF; + dmi_ver = get_unaligned_be32(buf + 6) & 0xFFFFFF; dmi_num = 0; /* No longer specified */ dmi_len = get_unaligned_le32(buf + 12); dmi_base = get_unaligned_le64(buf + 16); -- cgit v0.10.2 From 9ea650c804404e55dbf17c928203141282e759ab Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 25 Jun 2015 09:06:57 +0200 Subject: firmware: dmi: struct dmi_header should be packed Apparently the compiler does fine without it, but it feels safer and clearer to add the missing attribute. Signed-off-by: Jean Delvare diff --git a/include/linux/dmi.h b/include/linux/dmi.h index 2f9f988..5055ac3 100644 --- a/include/linux/dmi.h +++ b/include/linux/dmi.h @@ -75,7 +75,7 @@ struct dmi_header { u8 type; u8 length; u16 handle; -}; +} __packed; struct dmi_device { struct list_head list; -- cgit v0.10.2