[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1332785571-1475-1-git-send-email-prarit@redhat.com>
Date: Mon, 26 Mar 2012 14:12:51 -0400
From: Prarit Bhargava <prarit@...hat.com>
To: linux-kernel@...r.kernel.org
Cc: Prarit Bhargava <prarit@...hat.com>
Subject: [PATCH] dmi, Use little-endian for sysfs PRODUCT UUID
I noticed this discrepancy between the output of 'dmidecode -t 1 | grep
UUID' and the output of /sys/class/dmi/id/product_uuid:
[root@...el-mahobay-01 ~]# cat /sys/class/dmi/id/product_uuid
001320FB-4C2D-0013-20FB-4C2D001320FB
[root@...el-mahobay-01 ~]# dmidecode | grep UUID
UUID: FB201300-2D4C-1300-20FB-4C2D001320FB
Section 7.2.1, "System -- UUID" of the SMBIOS Specification (version
2.7.1) states:
Although RFC 4122 recommends network byte order for all fields, the PC
industry (including the ACPI, UEFI, and Microsoft specifications) has
consistently used little-endian byte encoding for the first three
fields: time_low, time_mid, time_hi_and_version. The same encoding, also
known as wire format, should also be used for the SMBIOS representation of
the UUID.
The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be
represented as:
33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
However, A comment in the dmidecode utility contains the following warning:
* As of version 2.6 of the SMBIOS specification, the first 3
* fields of the UUID are supposed to be encoded on little-endian.
* The specification says that this is the defacto standard,
* however I've seen systems following RFC 4122 instead and use
* network byte order, so I am reluctant to apply the byte-swapping
* for older versions.
Apply this same logic to the output of the kernel's representation for SMBIOS
Product UUID.
After the patch is applied on a system with SMBIOS version 2.6,
[root@...el-mahobay-01 ~]# cat /sys/class/dmi/id/product_uuid
FB201300-2D4C-1300-20FB-4C2D001320FB
[root@...el-mahobay-01 ~]# dmidecode | grep UUID
UUID: FB201300-2D4C-1300-20FB-4C2D001320FB
Signed-off-by: Prarit Bhargava <prarit@...hat.com>
---
drivers/firmware/dmi_scan.c | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 153980b..ef41d90 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -15,6 +15,9 @@
*/
static char dmi_empty_string[] = " ";
+/* SMBIOS version in MMmm format */
+static u16 smbios_version;
+
/*
* Catch too early calls to dmi_check_system():
*/
@@ -169,7 +172,18 @@ static void __init dmi_save_uuid(const struct dmi_header *dm, int slot, int inde
if (!s)
return;
- sprintf(s, "%pUB", d);
+ /*
+ * As of version 2.6 of the SMBIOS specification, the first 3
+ * fields of the UUID are supposed to be encoded on little-endian.
+ * The specification says that this is the defacto standard,
+ * however we've seen systems following RFC 4122 instead and use
+ * network byte order, so do not apply the byte-swapping
+ * for older versions.
+ */
+ if (smbios_version >= 0x0206)
+ sprintf(s, "%pUL", d);
+ else
+ sprintf(s, "%pUB", d);
dmi_ident[slot] = s;
}
@@ -411,9 +425,12 @@ static int __init dmi_present(const char __iomem *p)
* DMI version 0.0 means that the real version is taken from
* the SMBIOS version, which we don't know at this point.
*/
- if (buf[14] != 0)
+ if (buf[14] != 0){
printk(KERN_INFO "DMI %d.%d present.\n",
buf[14] >> 4, buf[14] & 0xF);
+ smbios_version = (((buf[14] >> 4) << 8) +
+ (buf[14] & 0xF));
+ }
else
printk(KERN_INFO "DMI present.\n");
if (dmi_walk_early(dmi_decode) == 0) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists