Re: [patch 2.5] PCI: allow alternative methods for probing the BARs

Grant Grundler (grundler@cup.hp.com)
Mon, 6 Jan 2003 13:52:10 -0800


On Mon, Jan 06, 2003 at 06:33:28PM +0300, Ivan Kokshaysky wrote:
> For now I'd start with following:
> phase #1. pci_do_scan_bus() - build the bus/device tree, read in
> dev/vendor IDs, header type and class code; call
> "PCI_FIXUP_EARLY" fixups.

you meant pci_scan_bus() for #1?

(pci_do_scan_bus() is the implementation, but I thought arch code
is supposed to call pci_scan_bus().)

> phase #2. pci_probe_resources(bus) - walk the bus tree again,
> probe the BARs, maybe call pci_read_bridge_bases for
> bridges; fill in the rest of PCI header; call "PCI_FIXUP_HEADER"
> fixups.
> (Also there are phases #3 and #4 - assign resources and assign unassigned
> resources, but it's another story)
...
> Hmm, this looks good - now we can do early bus-specific fixups
> without introducing "pcibios_init_bus" thing (suggested by Grant and
> myself quite a while ago).

I agree - it looks better. But I fail to see how it fixes the problem
of knowing when we can or cannot disable a device in order to size
the BAR. I'm under the impression some i386 specific code needs to be added
to identify/fixup the broken configurations (memory disabled when
a PCI Bridge is disabled).

I'm thinking the same logic needed by PCI hotplug to allow safe removal
of a bridge device would be useful to determine if a PCI Bridge could
be safely (temporarily) disabled (I'm thinking 4-port 100BT card).
Ie a "no subordinate drivers active" and "not in use" checking.

thanks,
grant
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/