linux-stable.git/drivers/firmware/dmi_scan.c, branch linux-4.3.y

firmware: dmi_scan: Coding style cleanups

2015-06-25T07:06:57+00:00

Signed-off-by: Jean Delvare

firmware: dmi_scan: add SBMIOS entry and DMI tables

2015-06-25T07:06:56+00:00

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

firmware: dmi_scan: Trim DMI table length before exporting it

2015-06-25T07:06:56+00:00

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

firmware: dmi_scan: Rename dmi_table to dmi_decode_table

2015-06-25T07:06:56+00:00

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

firmware: dmi_scan: Only honor end-of-table for 64-bit tables

2015-06-25T07:06:55+00:00

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

firmware: dmi_scan: Fix ordering of product_uuid

2015-05-14T12:40:50+00:00

In function dmi_present(), dmi_walk_early() calls dmi_table(), which
calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last
function makes a decision based on the value of global variable
dmi_ver. The problem is that this variable is set right _after_
dmi_walk_early() returns. So dmi_save_uuid() always sees dmi_ver == 0
regardless of the actual version implemented.

This causes /sys/class/dmi/id/product_uuid to always use the old
ordering even on systems implementing DMI/SMBIOS 2.6 or later, which
should use the new ordering.

This is broken since kernel v3.8 for legacy DMI implementations and
since kernel v3.10 for SMBIOS 2 implementations. SMBIOS 3
implementations with the 64-bit entry point are not affected.

The first breakage does not matter much as in practice legacy DMI
implementations are always for versions older than 2.6, which is when
the UUID ordering changed. The second breakage is more problematic as
it affects the vast majority of x86 systems manufactured since 2009.

Signed-off-by: Jean Delvare 
Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists")
Fixes: 79bae42d51a5 ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()")
Acked-by: Zhenzhong Duan 
Cc: Ben Hutchings 
Cc: Artem Savkov 
Cc: Ivan Khoronzhuk 
Cc: Matt Fleming 
Cc: stable@vger.kernel.org [v3.10+]

firmware: dmi_scan: Simplified displayed version

2015-05-14T12:40:50+00:00

The trailing .x adds no information for the reader, and if anyone
tries to parse that line, this is more work as they have 3 different
formats to handle instead of 2. Plus, this makes backporting fixes
harder.

Signed-off-by: Jean Delvare 
Fixes: 95be58df74a5 ("firmware: dmi_scan: Use full dmi version for SMBIOS3")
Cc: Ivan Khoronzhuk

Merge branch 'core-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2015-04-13T17:22:30+00:00

Pull EFI update from Ingo Molnar:
 "This tree includes various fixes, cleanups, a new efi=debug boot
  option and EFI boot stub memory allocation optimizations"

* 'core-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi/libstub: Retrieve FDT size when loaded from UEFI config table
  efi: Clean up the efi_call_phys_[prolog|epilog]() save/restore interaction
  efi: Disable interrupts around EFI calls, not in the epilog/prolog calls
  x86/efi: Add a "debug" option to the efi= cmdline
  firmware: dmi_scan: Use direct access to static vars
  firmware: dmi_scan: Use full dmi version for SMBIOS3

firmware: dmi_scan: Prevent dmi_num integer overflow

2015-03-27T10:53:46+00:00

dmi_num is a u16, dmi_len is a u32, so this construct:

	dmi_num = dmi_len / 4;

would result in an integer overflow for a DMI table larger than
256 kB. I've never see such a large table so far, but SMBIOS 3.0
makes it possible so maybe we'll see such tables in the future.

So instead of faking a structure count when the entry point does
not provide it, adjust the loop condition in dmi_table() to properly
deal with the case where dmi_num is not set.

This bug was introduced with the initial SMBIOS 3.0 support in commit
fc43026278b2 ("dmi: add support for SMBIOS 3.0 64-bit entry point").

Signed-off-by: Jean Delvare 
Cc: Matt Fleming 
Cc: Ivan Khoronzhuk 
Cc: 
Acked-by: Ard Biesheuvel 
Signed-off-by: Matt Fleming

firmware: dmi_scan: Use direct access to static vars

2015-03-26T14:00:15+00:00

There is no reason to pass static vars to function that can use
only them.

The dmi_table() can use only dmi_len and dmi_num static vars, so use
them directly. In this case we can freely change their type in one
place and slightly decrease redundancy.

Signed-off-by: Ivan Khoronzhuk 
Signed-off-by: Matt Fleming