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 first place anyway. Simplify the code and directly display the
8-bit PCI device class and sub-class values as-is.
Fixes: 3e86b5d3a228 ("dmioem: Decode HPE OEM Record 203")
Signed-off-by: Jean Delvare <jdelv...@suse.de>
---
The sign extension does not happen on all architectures, it depends
whether "char" is considered signed or not. This makes the code not
portable and this is how I noticed the problem.
An alternative fix would be to display the PCI device class as a
whole as one 16-bit number (as lspci is doing) instead of splitting it
into a class code and a sub class code.
As a side note, I wonder if we should get rid of dmi_hp_203_pciinfo()
altogether. Whether the device is present or not was already tested
before, testing it again is redundant and should not be needed. I
checked on my collection of dumps and it indeed made no difference.
dmioem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- dmidecode.orig/dmioem.c
+++ dmidecode/dmioem.c
@@ -1205,8 +1205,8 @@ static int dmi_decode_hp(const struct dm
dmi_hp_203_pciinfo("PCI Device ID", WORD(data +
0x0A));
dmi_hp_203_pciinfo("PCI Sub Vendor ID",
WORD(data + 0x0C));
dmi_hp_203_pciinfo("PCI Sub Device ID",
WORD(data + 0x0E));
- dmi_hp_203_pciinfo("PCI Class Code",
(char)data[0x10]);
- dmi_hp_203_pciinfo("PCI Sub Class Code",
(char)data[0x11]);
+ pr_attr("PCI Class Code", "0x%02x", data[0x10]);
+ pr_attr("PCI Sub Class Code", "0x%02x",
data[0x11]);
}
dmi_hp_203_assoc_hndl("Parent Handle", WORD(data +
0x12));
pr_attr("Flags", "0x%04X", WORD(data + 0x14));
--
Jean Delvare
SUSE L3 Support
