[Top] [All Lists]

PCI fixups (Was: Re: More linker magic..)

To: Ralf Baechle <>
Subject: PCI fixups (Was: Re: More linker magic..)
From: Martin Mares <>
Date: Thu, 5 Aug 1999 15:55:38 +0200
Cc: Linus Torvalds <>, Andi Kleen <>, David Hinds <>, Pete Zaitcev <>,,,,,,
In-reply-to: <>; from Ralf Baechle on Thu, Aug 05, 1999 at 02:23:03PM +0200
References: <> <> <> <>
Hi Ralf,

> 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   <>
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"People disagree with me.  I just ignore them." -- Linus Torvalds

<Prev in Thread] Current Thread [Next in Thread>