Re: pcnet32 devices with incorrect trident vendor ID

Matthew Wilcox (matthew@wil.cx) said: 

On Thu, Jan 12, 2006 at 01:57:14PM -0700, Matthew Wilcox wrote:

quoted

On Thu, Jan 12, 2006 at 08:49:42PM +0000, Daniel Drake wrote:

quoted

interesting:

http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html

The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to 
2.6, it changed to Trident.

It looks to me like there used to be a quirk that knew about this bug
and fixed it.

The reason I say this is that the lspci -x dumps are the same -- both
featuring the wrong vendor ID.  Want to dig through 2.4 and look for
this quirk?

Oh -- found it.  It's still in 2.6:

static void
fixup_broken_pcnet32(struct pci_dev* dev)
{
        if ((dev->class>>8 == PCI_CLASS_NETWORK_ETHERNET)) {
                dev->vendor = PCI_VENDOR_ID_AMD;
                pci_write_config_word(dev, PCI_VENDOR_ID, PCI_VENDOR_ID_AMD);
        }
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TRIDENT, PCI_ANY_ID,                     
fixup_broken_pcnet32);

Wonder why it isn't working now ... someone with a PPC box needs to check
(a) whether this function is being called and (b) if it is called, why
it's not doing what it's supposed to.

I remember looking at this a while back. I think the corrected information
is only being propagated to the 'vendor' file, and the write_config_word
isn't actually updating the 'config' entry in sysfs.

If you remove the "#if 0" from lib/sysfs.c in pciutils, it should
start reporting the corrected value in base lspci, etc.

Bill