Hi Jerry, On Fri, 6 Jun 2025 17:53:13 -0600, Jerry Hoemann wrote: > On Thu, Jun 05, 2025 at 08:28:20PM +0200, Jean Delvare wrote: > > 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. > > I have a single counter example of an ML150 Gen 9 where using the proposed > patch: > > ./dmidecode -t 203 --from-dump > /home/hoemann/Work/tools/dmidecode/dump2/ML150G9.dmi > > ... > > Handle 0x00B9, DMI type 203, 34 bytes > HP Device Correlation Record > Associated Device Record: 0x009E > Associated SMBus Record: N/A > PCI Vendor ID: 0x103c > PCI Device ID: 0x193f > PCI Sub Vendor ID: 0x103c > PCI Sub Device ID: 0x3381 > PCI Class Code: 0xff > PCI Sub Class Code: 0x00 > > So, such situations exists. > > This is from 2017 Bios and might be a bios defect. I know the owner > of this particular system and will get an updated dump to see if issue > remains.
The PCI data above is valid. PCI Base Class 0xFF is legal (means "Device does not fit in any defined classes" according to the PCI Code and ID Assignment Specification). -- Jean Delvare SUSE L3 Support
