PCI-Express support

[M. Warner Losh]

In message: <410D2FEA.5050504 at samsco.org>
            Scott Long <scottl at samsco.org> writes:
: Proper support likely entails splitting up the pci host-bridge drivers
: so that a given ACPI or legacy front-end can plug into a given enhanced
: or legacy configuration layer.  This definitely is not going to happen
: in time for 5.3, though.  A hack that could work for 5-STABLE would be
: to provide pcie_[read|write]_config() methods that would compliment the
: existing pci methods and be available for drivers that want to access
: the >255 configuration addresses.  Devices are already showing up that
: want to use these registers, btw.  The mechanics of doing this would
: involve using pmap_mapdev() to map in the range that is specific to each
: function, and then hang this information off of the pcicfg structure.
: It's a bit hackish, yes, but it does seem to work in tests that a
: colleague of mine has done.

Why not just have the bridge do a bus_alloc_resource for those things?
That would cause the pmap_mamdev() to happen behind the scenes.  We
already do a number of things like this in the CardBus driver, but on
a smaller scale.

But is there really a reason we need pcie_*_config routines?  wouldn't
the pcib_* routines do the same job nicely?  They are already
virtualized so that we can plug in the pcie bridge functionality to
the existing bridge drivers if there is a pcie structure allocated to
the pcicfg.  Why invent an interface that we know we're going to
deprecate in short order when the existing interface can be used.

In the pci_pci.c code, we could add a couple of ifs in
pcib_{read,write}_config if the bridge supports it, for example.

Warner