When I run the crate binary with the latest commit, I noticed my WiFi NIC showed up as a 'Mass Storage Controller'. However, standard lspci binary shows the device as a 'Network controller'.
Peering into the PCI class file generated by the build, the 'Mass storage controller' is the first entry for the 'Network Controller' class and there is no 'Network controller' subclass entry either. Comparing to the pci.ids file (specifically this section) parsed by the build, the Mass storage controller is actually part of the previous section.
(2, PciClassEntry { id : 2u8 , name : "Network controller" , subclasses : & [PciSubclassEntry { id : 128u8 , name : "Mass storage controller" , progs : & [] } , PciSubclassEntry { id : 0u8 , name : "Ethernet controller" , progs : & [] } , ... PciSubclassEntry { id : 8u8 , name : "Fabric controller" , progs : & [] }] }),
From what I can tell, this is a bug in the PCI class parsing logic. It appears to affect all PCI classes as well as parsing PCI devices. I'll post a PR soon to address this the PCI class portion. If I have time, I may post a follow-up PR for the PCI device parsing logic.
When I run the crate binary with the latest commit, I noticed my WiFi NIC showed up as a 'Mass Storage Controller'. However, standard
lspci
binary shows the device as a 'Network controller'.Peering into the PCI class file generated by the build, the 'Mass storage controller' is the first entry for the 'Network Controller' class and there is no 'Network controller' subclass entry either. Comparing to the
pci.ids
file (specifically this section) parsed by the build, theMass storage controller
is actually part of the previous section.From what I can tell, this is a bug in the PCI class parsing logic. It appears to affect all PCI classes as well as parsing PCI devices. I'll post a PR soon to address this the PCI class portion. If I have time, I may post a follow-up PR for the PCI device parsing logic.