Messages in this thread Patch in this message | | | From | Prarit Bhargava <> | Subject | [PATCH] dmi, Use little-endian for sysfs PRODUCT UUID | Date | Mon, 26 Mar 2012 14:12:51 -0400 |
| |
I noticed this discrepancy between the output of 'dmidecode -t 1 | grep UUID' and the output of /sys/class/dmi/id/product_uuid:
[root@intel-mahobay-01 ~]# cat /sys/class/dmi/id/product_uuid 001320FB-4C2D-0013-20FB-4C2D001320FB [root@intel-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@intel-mahobay-01 ~]# cat /sys/class/dmi/id/product_uuid FB201300-2D4C-1300-20FB-4C2D001320FB [root@intel-mahobay-01 ~]# dmidecode | grep UUID UUID: FB201300-2D4C-1300-20FB-4C2D001320FB
Signed-off-by: Prarit Bhargava <prarit@redhat.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
| |