Re: proper way to assign fixed PCI resources to a "hotplug" device

[thockin@hockin.org]

On Wed, Mar 08, 2006 at 02:39:52PM +0300, Ivan Kokshaysky wrote:
> On Tue, Mar 07, 2006 at 09:27:23PM -0800, Greg KH wrote:
> > On Wed, Mar 08, 2006 at 11:31:31AM +0900, Tejun Heo wrote:
> > > So, the problem is that the chip actually disables the PCI BAR if 
> > > certain switches aren't turned on and thus BIOSes are likely not to 
> > > reserve mmio address for the BAR. We can turn on proper switches during 
> > > driver initialization but we don't know how to wiggle the BAR into mmio 
> > > address space.
> > 
> > Thanks for the explaination, that makes more sense.  Unfortunatly I do
> > not know how to do this right now :(
> > 
> > Anyone with any ideas?
> 
> We have 'pci_fixup_early' stuff exactly for that sort of hardware.
> IOW, just add a quirk routine that turns on desired mode of the
> device and use DECLARE_PCI_FIXUP_EARLY() for it.
> The new BAR will be discovered an assigned automatically then.

Assigned from what pool?  BIOS most likely sizes the hole to be a pretty
tight fit for all the resources it knows about.  If there is suddenly a
new resource, you're in trouble.

The problem is that we don't know explicitly where or how big the hole is,
how it is allocated (prefetch or non).  Then, even if we *did* know, we
don't know that there's enough space for an arbitrary device to show up
later.

In BIOSes I control we enable the BARs and allocate regions for them and
then turn them off if need be.

There really isn't a good generic answer to this that will work with
existing BIOSes.  My first instinct is to call this a BIOS bug.

We could teach linux about chipsets and let Linux re-do the whole
PCI-allocation process.   But that's not an easy task, and is probably a
contentious idea.

Tim