[PATCH 0/1] Decode HPE OEM Type 202

2025-06-05 Thread Jerry Hoemann via dmidecode-devel
DIMM Location Record (Type 202) This record allows the Systems Management (Health) Driver (or any Software) to correlate a Type 17 Memory Device Record with a specific DIMM (DIMM, Board, and/or Processor number if appropriate). Type 17 Records only have a text string to indicate the DIMM number

[PATCH 1/1] dmioem: Decode HPE OEM Type 202

2025-06-05 Thread Jerry Hoemann via dmidecode-devel
Record type 202: DIMM Location Record Signed-off-by: Jerry Hoemann --- dmioem.c | 90 1 file changed, 90 insertions(+) diff --git a/dmioem.c b/dmioem.c index d4d83e2..b5d0402 100644 --- a/dmioem.c +++ b/dmioem.c @@ -1147,6 +1147,96 @@ sta

[PATCH] dmioem: Fix HPE type 203 PCI device class and sub-class

2025-06-05 Thread Jean Delvare
Casting the PCI device class to a signed 8-bit type before extending it to a 16-bit type causes the sign bit to replicate to the whole upper byte. For example, a sub-class value of 0x80 ends up being displayed as 0xFF80. It doesn't make sense to display an 8-bit value using a 16-bit format in the

[PATCH] dmioem: Fix HPE type 199 on theoretical big-endian systems

2025-06-05 Thread Jean Delvare
dmi_print_cpuid() expects a pointer to raw data to interpret as a CPUID, not to a native integer. If we call DWORD() on the data before calling dmi_print_cpuid(), and once again in dmi_print_cpuid(), we end up swapping the bytes twice if running on a big-endian system, which causes completely wrong