[RFC/PATCH] Set up PCI tree from OF on ppc64

[Matthew Wilcox]

On Thu, Aug 25, 2005 at 05:42:07PM +0200, Segher Boessenkool wrote:
> Why does it have to be disabled for probing?  The kernel really
> shouldn't change bus numbers and address ranges and BARs if the
> firmware already has done this.  If the firmware has disabled a
> device (or bridge, or just some BARs), it probably has a good
> reason to do so.  On the other hand, there might be a lot of
> broken firmwares out there, of course -- but not nearly as much
> as on x86, so we don't need all those fixups they use.

In order to size a BAR, you read its current value, write 0xffffffff
to it, read it back, see how many bits are 0, then write the original
value back.  It's a fundamentally destructive process [1] during the
window between writing 0xffffffff and restoring the original value.

[1] Which is why cpqphp_pci, ibmphp_pci, pciehp_pci and shpchp_pci are
broken.  They're loadable as a module, and will probe the BARs of devices
with currently running drivers.  If an interrupt comes in at the wrong
time, splat.  I fixed acpiphp and I guess I'll have to fix pciehp soon ;-(
They're such ugly drivers ... and so much copy-and-pasted code between them.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain