> SGI IOC3 is another case. This card only decodes the first 32 bytes of
> the configuration space, so the a few bogus mappings will be detected by
> the PCI code. Any generic facility for this or what is your proposed
> way of handling such cards?
As the reality continues supplying us with buggy PCI devices with
almost all conceivable faults, I'm going to extend the fixup mechanisms
in our PCI code and re-arrange the device probing. There will exist
two fixup tables: a generic one and an arch-specific one (the latter
will contain fixups for arch-specific bridges etc.) and each fixup
entry will consist of entry type (telling when should be the fixup
activated), vendor+device ID and a function pointer. The generic code
will automatically call these fixups during bus scan.
New bus scan algorithm:
for each bus {
for each device on that bus {
read configuration header
READ FIXUP [table lookup; fix broken headers]
}
BUS FIXUP [function call; fix ghost buses et cetera]
scan child buses
}
GLOBAL FIXUP [function call; assigns addresses and so on]
claim resources for all cards
FINAL FIXUP [again a function call; fixes forgotten I/O enables etc.]
QUIRKS [table lookup; fixes the remaining problems]
Host bridge scanning will be no longer initiated by the generic code -- there
will be an arch-dependent function which will call pci_scan_bus for all host
bridges it knows, passing struct pci_ops containing pointers to configuration
space access function for that bridge, so that the architectures won't have
to do their own multiplexing inside low-level access functions.
I'd like to know your opinion on this approach.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "People disagree with me. I just ignore them." -- Linus Torvalds- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/