PCI-Express support

[Scott Long]

M. Warner Losh wrote:
> 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

First, doing this the Right Way is not going to happen for 5.x.  I'm 
just trying to define an API to bridge us over for the short term.
There is no emulation shim defined for the extended config space, so
either we support it or we don't.  As as I said, there are already
devices showing up that want to use the extended registers.

Second, I'm trying to approach this in the least disruptive manner.
Yes, it could be abstracted so that pci_config_read|write() would
do the right things, but that would add risk to a whole lot of code
that we don't want to rototill at the moment.

Scott