[SPARC64]: Fix sabre pci controllers with new probing scheme.
authorDavid S. Miller <davem@ultra5.davemloft.net>
Sun, 4 Mar 2007 20:53:19 +0000 (12:53 -0800)
committerDavid S. Miller <davem@sunset.davemloft.net>
Thu, 26 Apr 2007 08:55:10 +0000 (01:55 -0700)
commit01f94c4a6ced476ce69b895426fc29bfc48c69bd
tree68866108644a1e90ae7688d2e35cb8462ab6a07c
parenta378fd0ee8ea6af5dafd0ab3d634f22b926b5ac4
[SPARC64]: Fix sabre pci controllers with new probing scheme.

The SIMBA APB bridge is strange, it is a PCI bridge but it lacks
some standard OF properties, in particular it lacks a 'ranges'
property.

What you have to do is read the IO and MEM range registers in
the APB bridge to determine the ranges handled by each bridge.
So fill in the bus resources by doing that.

Since we now handle this quirk in the generic PCI and OF device
probing layers, we can flat out eliminate all of that code from
the sabre pci controller driver.

In fact we can thus eliminate completely another quirk of the sabre
driver.  It tried to make the two APB bridges look like PBMs but that
makes zero sense now (and it's questionable whether it ever made sense).
So now just use pbm_A and probe the whole PCI hierarchy using that as
the root.

This simplification allows many future cleanups to occur.

Also, I've found yet another quirk that needs to be worked around
while testing this.  You can't use the 'class-code' OF firmware
property, especially for IDE controllers.  We have to read the value
out of PCI config space or else we'll see the value the device was
showing before it was programmed into native mode.

I'm starting to think it might be wise to just read all of the values
out of PCI config space instead of using the OF properties. :-/

Signed-off-by: David S. Miller <davem@davemloft.net>
arch/sparc64/kernel/of_device.c
arch/sparc64/kernel/pci.c
arch/sparc64/kernel/pci_sabre.c