Re: PCI bus numbering and orphaned devices

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:
> > 
> > Ok, attached is a patched I tried,
> 
> Hmmm, you seem to have forgotten to actually attach it.

Ok, this time I'll attach it!

> > but sad to say, this doesn't work
> > out to well.  I added a printf before and after the REG statement, and
> > a boot with the kernel give this output:
> > found-> vendor=0x108e, dev=0x5000, revid=0x13
> >         bus=0, slot=1, func=1
> >         class=06-04-00, hdrtype=0x01, mfdev=1
> >         cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords)
> >         lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns)
> > about to read HEADERTYPE
> > panic: trap: data access error
> >
> > [...]
> > 
> > the last three lines repeate for a while, but this is because of:
> > psycho_read_config(...)
> > [...]
> > 	/*
> > 	 * The psycho bridge does not tolerate accesses to unconfigured PCI
> > 	 * devices' or function's config space, so look up the device in the
> > 	 * firmware device tree first, and if it is not present, return a value
> > 	 * that will make the detection code think that there is no device here.
> > 	 * This is ugly...
> > 	 */
> > 	if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0)
> > 		return (0xffffffff);
> > 
> > Which obviously will fail if reg != 0 which we try to do when reading
> > the PCIR_HEADERTYPE..
> > 
> > So, the question is, does other arch's do something nasty like this
> > too?  Should I change the check to just do ofw_pci_find_node?
> 
> You could safely (it would just be slow), but that alone would not
> help you, since you would also be ignoring requests to the registers
> you want to read without further hackery. You could, of course, look
> into the device tree to see if there are devices at higher functions,
> that would just make that kludge more ugly than it already is :)

Ok, right now in order to get the machine back up and functional I
did remove the reg == 0, and running scanning all the functions.

> 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!

> > 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.)

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

Thanks, I have plenty of time to hack on this right now, so any pointers
would be useful.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."