linux-toradex.git/drivers/firmware/dmi_scan.c, branch v3.2.68

dmi: add support for exact DMI matches in addition to substring matching

2014-05-18T13:58:06+00:00

commit 5017b2851373ee15c7035151853bb1448800cae2 upstream.

dmi_match() considers a substring match to be a successful match.  This is
not always sufficient to distinguish between DMI data for different
systems.  Add support for exact string matching using strcmp() in addition
to the substring matching using strstr().

The specific use case in the i915 driver is to allow us to use an exact
match for D510MO, without also incorrectly matching D510MOV:

  {
	.ident = "Intel D510MO",
	.matches = {
		DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
		DMI_EXACT_MATCH(DMI_BOARD_NAME, "D510MO"),
	},
  }

Signed-off-by: Jani Nikula 
Cc: 
Cc: Chris Wilson 
Cc: Cornel Panceac 
Acked-by: Daniel Vetter 
Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

dmi_scan: fix missing check for _DMI_ signature in smbios_present()

2013-03-20T15:03:24+00:00

commit a40e7cf8f06b4e322ba902e4e9f6a6b0c2daa907 upstream.

Commit 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version
from SMBIOS if it exists") hoisted the check for "_DMI_" into
dmi_scan_machine(), which means that we don't bother to check for
"_DMI_" at offset 16 in an SMBIOS entry.  smbios_present() may also call
dmi_present() for an address where we found "_SM_", if it failed further
validation.

Check for "_DMI_" in smbios_present() before calling dmi_present().

[akpm@linux-foundation.org: fix build]
Signed-off-by: Ben Hutchings 
Reported-by: Tim McGrath 
Tested-by: Tim Mcgrath 
Cc: Zhenzhong Duan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists

2013-02-06T04:33:53+00:00

commit 9f9c9cbb60576a1518d0bf93fb8e499cffccf377 upstream.

The right dmi version is in SMBIOS if it's zero in DMI region

This issue was originally found from an oracle bug.
One customer noticed system UUID doesn't match between dmidecode & uek2.

 - HP ProLiant BL460c G6 :
   # cat /sys/devices/virtual/dmi/id/product_uuid
   00000000-0000-4C48-3031-4D5030333531
   # dmidecode | grep -i uuid
   UUID: 00000000-0000-484C-3031-4D5030333531

From SMBIOS 2.6 on, spec use little-endian encoding for UUID other than
network byte order.

So we need to get dmi version to distinguish.  If version is 0.0, the
real version is taken from the SMBIOS version.  This is part of original
kernel comment in code.

[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Zhenzhong Duan 
Cc: Feng Jin 
Cc: Jean Delvare 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

drivers/firmware/dmi_scan.c: check dmi version when get system uuid

2013-02-06T04:33:53+00:00

commit f1d8e614d74b09531b9a85e812485340f3df7b1c upstream.

As of version 2.6 of the SMBIOS specification, the first 3 fields of the
UUID are supposed to be little-endian encoded.

Also a minor fix to match variable meaning and mute checkpatch.pl

[akpm@linux-foundation.org: tweak code comment]
Signed-off-by: Zhenzhong Duan 
Cc: Feng Jin 
Cc: Jean Delvare 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

efi: Make 'efi_enabled' a function to query EFI facilities

2013-02-06T04:33:50+00:00

commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream.

Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.

The immediate motivation for this patch is the bug report at,

    https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557

which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,

    https://bugzilla.kernel.org/show_bug.cgi?id=47121

details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,

    if (!efi_enabled)

hasn't been a sufficient condition for quite some time.

Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.

For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).

This patch is a prereq for the samsung-laptop fix patch.

Cc: David Airlie 
Cc: Corentin Chary 
Cc: Matthew Garrett 
Cc: Dave Jiang 
Cc: Olof Johansson 
Cc: Peter Jones 
Cc: Colin Ian King 
Cc: Steve Langasek 
Cc: Tony Luck 
Cc: Konrad Rzeszutek Wilk 
Cc: Rafael J. Wysocki 
Signed-off-by: Matt Fleming 
Signed-off-by: H. Peter Anvin 
[bwh: Backported to 3.2:
 - Adjust context (a lot)
 - Add efi_is_native() function from commit 5189c2a7c776
   ('x86: efi: Turn off efi_enabled after setup on mixed fw/kernel')
 - Make efi_init() bail out when booted non-native, as it would previously
   not be called in this case
 - Drop inapplicable changes to start_kernel()]
Signed-off-by: Ben Hutchings

dmi: Feed DMI table to /dev/random driver

2012-09-12T02:37:30+00:00

commit d114a33387472555188f142ed8e98acdb8181c6d upstream.

Send the entire DMI (SMBIOS) table to the /dev/random driver to
help seed its pools.

Signed-off-by: Tony Luck 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Ben Hutchings

drivers/firmware/dmi_scan.c: make dmi_name_in_vendors more focused

2011-11-16T00:41:51+00:00

The current implementation of dmi_name_in_vendors() is an invitation to
lazy coding and false positives [1].  Searching for a string in 8 know
what you're looking for, so you should know where to look.  strstr isn't
fast, especially when it fails, so we should avoid calling it when it
just can't succeed.

Looking at the current users of the function, it seems clear to me that
they are looking for a system or board vendor name, so let's limit
dmi_name_in_vendors to these two DMI fields.  This much better matches
the function name, BTW.

[1] We currently have code looking for short names in DMI data, such as
"IBM", "ASUS" or "Acer".  I let you guess what will happen the day other
vendors ship products named, for example, "SCHREIBMEISTER", "PEGASUS" or
"Acerola".

Signed-off-by: Jean Delvare 
Cc: Andi Kleen 
Cc: Jesse Barnes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86, dmi, debug: Log board name (when present) in dmesg/oops output

2011-02-15T03:20:57+00:00

The "Type 2" SMBIOS record that contains Board Name is not
strictly required and may be absent in the SMBIOS on some
platforms.

( Please note that Type 2 is not listed in Table 3 in Sec 6.2
  ("Required Structures and Data") of the SMBIOS v2.7
  Specification. )

Use the Manufacturer Name (aka System Vendor) name.
Print Board Name only when it is present.

Before the fix:
  (i) dmesg output: DMI: /ProLiant DL380 G6, BIOS P62 01/29/2011
 (ii) oops output:  Pid: 2170, comm: bash Not tainted 2.6.38-rc4+ #3 /ProLiant DL380 G6

After the fix:
  (i) dmesg output: DMI: HP ProLiant DL380 G6, BIOS P62 01/29/2011
 (ii) oops output:  Pid: 2278, comm: bash Not tainted 2.6.38-rc4+ #4 HP ProLiant DL380 G6

Signed-off-by: Naga Chumbalkar 
Reviewed-by: Bjorn Helgaas 
Cc:  # .3x - good for debugging, please apply as far back as it applies cleanly
LKML-Reference: <20110214224423.2182.13929.sendpatchset@nchumbalkar.americas.hpqcorp.net>
Signed-off-by: Ingo Molnar

dmi: log board, system, and BIOS information

2010-10-28T01:03:05+00:00

Put basic system information in the dmesg log.  There are lots of dmesg
logs on the web, and it would be useful if they contained this information
for debugging platform problems.  "BOARD/PRODUCT" format copied from
show_regs_common(), which is used in the oops path.

Signed-off-by: Bjorn Helgaas 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Cc: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

PCI: export SMBIOS provided firmware instance and label to sysfs

2010-07-30T16:36:01+00:00

This patch exports SMBIOS provided firmware instance and label of
onboard PCI devices to sysfs.  New files are:
  /sys/bus/pci/devices/.../label which contains the firmware name for
the device in question, and
  /sys/bus/pci/devices/.../index which contains the firmware device type
instance for the given device.

Signed-off-by: Jordan Hargrave 
Signed-off-by: Narendra K 
Signed-off-by: Jesse Barnes