Re: PCI bus numbering and orphaned devices

On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote:
> M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600:
> > : > > 		hdrtype	= REG(PCIR_HEADERTYPE, 1);
> > : > This needs to be tested on that given hardware.
> > : > I don't know if REG will work as expected because it asks function 0,
> > : > which is disabled.
> > : 
> > : I've reread John-Mark's last mail about the readable registers.
> > : So - yes it should work.
> > 
> > That's what inspired me.  Also, I'd expected that we'd need some kind
> > of tweaking to make it actually compile and be neat.
> 
> Ok, attached is a patched I tried,

Hmmm, you seem to have forgotten to actually 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 :)

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

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

	- 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