Re: PCI bus numbering and orphaned devices

On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote:
> Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200:
> > On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote:
> > There's a similar problem with hme devices in some Netra models, and
> > so far I have just ignored this because of the ugliness involved
> > (there were patches floating around at one point, but I did not commit
> > them).
> > 
> > The real fix (and the way I wanted to implement things from the
> > beginning) is to write an OFW PCI bus, analogous to the ACPI one. This
> > is high on my list, waiting for time to become available :)
> 
> Yikes, I just started looking at the acpi code, and there's a lot of
> code in it!

There's much setup to be done that the firmware is too lazy to do for
us.
 
> > > Is this why pciconf -r is returning 0xffffffff when reading the ebus
> > > and firewire parts of the SME2300BGA?  Simply because it isn't in
> > > the ofw tree? 
> > 
> > Could be. We just cannot handle devices without firmware nodes - we
> > don't know whether we can safely access them, cannot assign interrupts
> > etc.
> 
> Ok, the only problem is that is then we have the same problem the ACPI
> code does in that hot swapping cards would have a problem.  Since it
> appears to me that the OFW tree doesn't get updated upon a swap.  (At
> least the usb part of the tree doesn't.)

We do not support hotplugging at the moment anyway. If a bridge driver
would implement that in the future without using any firmware support
however, it will then need to know everything information about the
interrupt routing required for its devices if it cannot use the
firmware for this. in that case, it can just prevent the ofw_pci bus
from attaching to it (this will be easily possible).
I'd hope that machines that support hot-plugging of PCI devices would
have firmware methods available to support that though.

> Does this mean that we should eliminate most of the Sun specific pci
> bus drivers in favor of OFW specific ones like ACPI? or?

No, it means introducing an OFW bus driver, which uses the firmware to
enumerate the devices and to support interrupt routing. The bridge
drivers would be mostly unaffected by this.
The only problem with this approach is that it can change the device
enumeration; I hope that the resulting one will be the same one that is
printed on the boxen, so it should be advantageous for new
installations, but a minor migration problem for old ones.

I've got some code for this already, it just isn't done yet.

	- Thomas

-- 
Thomas Moestl <t.moestl_at_tu-bs.de>	http://www.tu-bs.de/~y0015675/
              <tmm_at_FreeBSD.org>		http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0  9C0F 1FE6 4F1D 419C 776C