Re: PCI bus numbering and orphaned devices

From: John-Mark Gurney <gurney_j_at_efn.org>
Date: Tue, 10 Jun 2003 15:34:36 -0700
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, 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
cpuid = 0; 
Uptime: 1s
panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956
cpuid = 0; 
Uptime: 1s
panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956
cpuid = 0; 
Uptime: 1s

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

I don't have any data sheets or the PCI spec, so making heads or tails
of this is going be hard.

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

     "All that I will do, has been done, All that I have, has not."
Received on Tue Jun 10 2003 - 13:36:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:11 UTC