steve%prd.co.uk@localhost (Steve Blinkhorn) writes: > vendor 0x10ec product 0x8179 (miscellaneous network, revision 0x01) at > pci3 dev 0 function 0 not configured > > refers to pci3, whereas from the driver name I would have thought it > should appear as a usb device. That probe message is not from a particular driver. The PCI attach code is iterating over each PCI bus and if the vendor/product codes match attaching the device to a driver. This is just printing out that for this codepoint, no driver matched. If I were trying to figure this out, I would first understand a bit more clearly about PCI vs USB namespaces (the vendor/product codes). I think they are actually logically different, except that I wouldn't be surprised if the vendor codes are the same because of how allocating them takes some sort of industry association. Then within a vendor code, I suspect product codes might or might not line up between PCI and USB but I wouldn't be surprised if the internal codepoint assignment process assigned codes to chips across both. Certainly NetBSD having separate files indicates that the people who set that up think it's different, or did, or that they had some other reason. It may be that the next step is to add this vendor/product to the PCI device list. (That won't make it attach or work, but it probably leads to a nicer message saying that it didn't attach.) Then, if you can find out how this chip works from some other OS, or From actually getting a programming guide from the manufacturer, you can add it as a match in a driver that might be able to handle it. It might be a similar chip to one netbsd supports, but that also has a USB interface, and in your case the USB interface isn't being used.
Attachment:
signature.asc
Description: PGP signature