From: Jean Delvare <jdelvare@suse.de>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
Jordan Hargrave <jordan_hargrave@dell.com>,
Ivan Khoronzhuk <ivan.khoronzhuk@globallogic.com>
Subject: [PATCH] firmware: dmi_scan: Look for SMBIOS 3 entry point first
Date: Mon, 23 Jan 2017 17:48:43 +0100 [thread overview]
Message-ID: <20170123174843.2f681487@endymion> (raw)
Since version 3.0.0 of the SMBIOS specification, there can be
multiple entry points in memory, pointing to one or two DMI tables.
If both a 32-bit ("_SM_") entry point and a 64-bit ("_SM3_") entry
point are present, the specification requires that the latter points
to a table which is a super-set of the table pointed to by the
former. Therefore we should give preference to the 64-bit ("_SM3_")
entry point.
However, currently the code is picking the first valid entry point
it finds. Per specification, we should look for a 64-bit ("_SM3_")
entry point first, and if we can't find any, look for a 32-bit
("_SM_" or "_DMI_") entry point. Modify the code to do that.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
---
* Note 1: I can't test the 64-bit ("_SM3_") entry point case. I
would appreciate if someone with access to a machine supporting
legacy (non-UEFI) mode and implementing a 64-bit table could test
and report.
* Note 2: I'm not particularly happy with this change as it will
make the entry point scan 3 times slower on average for legacy
machines, but I couldn't come up with anything smarter. If anyone
can think of a better implementation, please let me know.
drivers/firmware/dmi_scan.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
--- linux-4.10-rc4.orig/drivers/firmware/dmi_scan.c 2017-01-04 14:05:09.392301072 +0100
+++ linux-4.10-rc4/drivers/firmware/dmi_scan.c 2017-01-16 11:55:24.500984728 +0100
@@ -649,6 +649,21 @@ void __init dmi_scan_machine(void)
goto error;
/*
+ * Same logic as above, look for a 64-bit entry point
+ * first, and if not found, fall back to 32-bit entry point.
+ */
+ memcpy_fromio(buf, p, 16);
+ for (q = p + 16; q < p + 0x10000; q += 16) {
+ memcpy_fromio(buf + 16, q, 16);
+ if (!dmi_smbios3_present(buf)) {
+ dmi_available = 1;
+ dmi_early_unmap(p, 0x10000);
+ goto out;
+ }
+ memcpy(buf, buf + 16, 16);
+ }
+
+ /*
* Iterate over all possible DMI header addresses q.
* Maintain the 32 bytes around q in buf. On the
* first iteration, substitute zero for the
@@ -658,7 +673,7 @@ void __init dmi_scan_machine(void)
memset(buf, 0, 16);
for (q = p; q < p + 0x10000; q += 16) {
memcpy_fromio(buf + 16, q, 16);
- if (!dmi_smbios3_present(buf) || !dmi_present(buf)) {
+ if (!dmi_present(buf)) {
dmi_available = 1;
dmi_early_unmap(p, 0x10000);
goto out;
--
Jean Delvare
SUSE L3 Support
reply other threads:[~2017-01-23 16:48 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170123174843.2f681487@endymion \
--to=jdelvare@suse.de \
--cc=ivan.khoronzhuk@globallogic.com \
--cc=jordan_hargrave@dell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wangkefeng.wang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.