[coreboot] pci_check_sanity is confusing; do we need VSA to read LX CS5536 config registers? ; how to handle VSA?

[ron minnich]

pci_sanity_check is confusing. It looks like this:
static int pci_sanity_check(const struct pci_bus_operations *o)
{
        u16 class, vendor;
        unsigned bus;
        int devfn;
        struct bus pbus; /* Dummy device */
#define PCI_CLASS_BRIDGE_HOST           0x0600
#define PCI_CLASS_DISPLAY_VGA           0x0300
#define PCI_VENDOR_ID_COMPAQ            0x0e11
#define PCI_VENDOR_ID_INTEL             0x8086
#define PCI_VENDOR_ID_MOTOROLA          0x1057

        for (bus = 0, devfn = 0; devfn < 0x100; devfn++) {
                class = o->read16(&pbus, bus, devfn, PCI_CLASS_DEVICE);
                vendor = o->read16(&pbus, bus, devfn, PCI_VENDOR_ID);
                printk(BIOS_SPEW, "%s: read @ devfn %04x class %04x
vendor %04x\n", __FUNCTION__, devfn, class, vendor);
                if (((class == PCI_CLASS_BRIDGE_HOST) || (class ==
PCI_CLASS_DISPLAY_VGA)) ||
                        ((vendor == PCI_VENDOR_ID_INTEL) || (vendor ==
PCI_VENDOR_ID_COMPAQ) ||
                                (vendor == PCI_VENDOR_ID_MOTOROLA))) {
                        return 1;
                }
        }
        printk(BIOS_ERR, "PCI: Sanity check failed\n");
        return 0;
}

So, why does finding an intel or moto or whatever mean it is sane?
What if you have no intel or moto? Or Bridge or VGA?
In the lspci from the alix1c, under standard bios, however, there is a
host bridge at 0:1.0. But under current v3, which does not run VSA, a
config read of 0:1.0 returns an 0xffff for all config registers.

Anyway, I added this:
               if (((class == PCI_CLASS_BRIDGE_HOST) || (class ==
PCI_CLASS_DISPLAY_VGA)) ||
                        ((vendor == PCI_VENDOR_ID_INTEL) || (vendor ==
PCI_VENDOR_ID_COMPAQ) ||
                        (vendor == PCI_VENDOR_ID_AMD) ||
<<<<<<----------------------------------------------------------
                                (vendor == PCI_VENDOR_ID_MOTOROLA))) {
                        return 1;
                }

I.e. check AMD too. Now it returns, but still, this is really weird:
devfn 00 (the north) returns 0xffff for the vendor and class. In fact
the first devfn that gets any AMD vendor id is devfn 0x78!

I thought that even without VSA, a pci config read of 0:1.0 would give
me something reasonable back. But the devices that are found without
VSA are 0:c.0, 0:d.0, and then 0:f.0 etc.

0:1.0 and 0:1.2 are not seen with pci config reads ... Marc is this
for real? I need VSA to do a config read of the geode companion?

Inquiring minds want to know, but I think they're going to sleep first.

I am wondering  for VSA if we should not have a post-ram step where we
find all LAR entries with names like
prestage2/*
and run them. Still not sure of the right approach for VSA. Is VSA so
special that we shouldn't worry about handling it in the general case?

thanks

ron