Re: PCI bus numbering and orphaned devices

From: John-Mark Gurney <gurney_j_at_efn.org>
Date: Tue, 10 Jun 2003 17:38:28 -0700
Bernd Walter wrote this message on Wed, Jun 11, 2003 at 01:16 +0200:
> On Tue, Jun 10, 2003 at 03:34:36PM -0700, John-Mark Gurney wrote:
> > 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.

It's amazing what reading the specs for a CPU can do.  The US-IIi
specificly has a section on this.  16.2.1 Probing PCI durning boot
using deferred errors.

Guess I'll be looking at implementing that.  Then we can get ride
of that ickyness in the psycho_read_config function.

-- 
  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 - 16:16:19 UTC

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