[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Freeipmi-devel] [PATCH 5/5] Correct order of bytes in specification_rev
From: |
dann frazier |
Subject: |
[Freeipmi-devel] [PATCH 5/5] Correct order of bytes in specification_revision field of ACPI SPMI table |
Date: |
Tue, 31 Jul 2018 11:42:27 -0600 |
According to section C3-1 in the IPMI specification, the
"Specification Revision (version)" field consistes of 2 bytes that:
"Identifies the IPMI specification revision, in BCD format, to which the
interface was designed. The first byte holds the most significant digits
of the revision, e.g., a a value of 0x0150 indicates the interface is
compatible with IPMI version v1.5."
Based on that reading alone, the current template looks correct. However,
earlier in the same section we have the text:
"Per [ACPI 2.0], unless otherwise specified, numeric values for the table
or structures are always encoded in little endian format."
It isn't clear to me if this was intended to apply to the "Specification
Revision" field or not. I mean, they are numeric values - but does the
text "in BCD format" and "The first byte holds the most significant digits"
trigger the "unless otherwise specified" exception?
Luckily, a sample of several BIOS's suggests vendors have implemented this
consistently, using little endian format:
+-------------------------------------------------------------------+
| System | IPMI Ver (SMBIOS) | ACPI Spec Rev Bytes |
| HiSilicon D06 | N/A | 00 02 |
| HP ProLiant DL165 G7[*] | 1.5 | 00 01 |
| HP ProLiant DL385 G7 | 2.0 | 00 02 |
| QuantaGrid D52B | 2.0 | 00 02 |
| Supermicro Super Server | 2.0 | 00 02 |
+-------------------------------------------------------------------+
[*] Clearly the SMBIOS and ACPI data here are inconsistent but, IMO,
"1.0" seems to be more likely the intent, vs. 0.1.
Without this change, ipmi-locate will report specifications of 0.1 and
0.2 instead of 1.0 and 2.0 on the sampled systems (all parsing done
via sysfs).
---
libfreeipmi/locate/ipmi-locate-acpi-spmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
b/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
index 587bcc24b..f6a9c4fe2 100644
--- a/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
+++ b/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
@@ -184,8 +184,8 @@ fiid_template_t tmpl_acpi_spmi_table_descriptor =
e.g. a value of 0x0150 indicates the interface is
compatible with IPMI version v1.5. */
/* {16, "specification_revision", FIID_FIELD_REQUIRED |
FIID_FIELD_LENGTH_FIXED}, */
- { 8, "specification_revision.major", FIID_FIELD_REQUIRED |
FIID_FIELD_LENGTH_FIXED},
{ 8, "specification_revision.minor", FIID_FIELD_REQUIRED |
FIID_FIELD_LENGTH_FIXED},
+ { 8, "specification_revision.major", FIID_FIELD_REQUIRED |
FIID_FIELD_LENGTH_FIXED},
/* Interrupt type(s) used by
the interface:
[0] - SCI triggered through GPE
--
2.18.0
- [Freeipmi-devel] [PATCH 0/5] Parse SPMI tables using sysfs, dann frazier, 2018/07/31
- [Freeipmi-devel] [PATCH 4/5] Allow sysfs SPMI parsing on ARM platforms, dann frazier, 2018/07/31
- [Freeipmi-devel] [PATCH 3/5] Add support for parsing SPMI table exposed via sysfs, dann frazier, 2018/07/31
- [Freeipmi-devel] [PATCH 2/5] Split RSDT/XSDT parsing into new function, dann frazier, 2018/07/31
- [Freeipmi-devel] [PATCH 1/5] Don't try to separate the header from the ACPI table data, dann frazier, 2018/07/31
- [Freeipmi-devel] [PATCH 5/5] Correct order of bytes in specification_revision field of ACPI SPMI table,
dann frazier <=
- Re: [Freeipmi-devel] [PATCH 0/5] Parse SPMI tables using sysfs, Albert Chu, 2018/07/31