Re: PCI bus numbering and orphaned devices

On Wed, 2003/06/11 at 01:16:50 +0200, Bernd Walter wrote:
> On Tue, Jun 10, 2003 at 03:34:36PM -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, 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?
> 
> Possible - in fact I was very surprised that a disabled device was not
> readable on some registers.
> We have a similar situation on alpha, where we get traps for reading non
> available devices.
> It's handled in that we tell the system to expect traps before accessing
> registers.
> This is done by reading with the badaddr function, which sets a flag for
> our trap handler so it can continue in case the device doesn't exist.
> badaddr() returns a flags which tells if reading was successfull.
> 
> > I don't have any data sheets or the PCI spec, so making heads or tails
> > of this is going be hard.
> 
> It's OK to get errors when reading locations that aren't available.
> Some chipsets nerver trap, others only trap for type2 access (behind
> Bridges) and some always trap.

I don't have the standard handy, but from my reading of the Shanley
book, it seems that for the vendor ID register, a host bridge is
required to return 0xffff if no device is present. Loading this task
off to the software is a bit annoying.
There is no mention of other registers, so reading them in the probe
might theoretically cause problems even on host bridges that handle
the vendor ID register correctly.

	- 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