From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 16:02:19 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77F0237B401 for ; Tue, 10 Jun 2003 16:02:19 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A5AFC43FCB for ; Tue, 10 Jun 2003 16:02:17 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 19180 invoked by uid 65534); 10 Jun 2003 23:02:16 -0000 Received: from p508E7664.dip.t-dialin.net (EHLO galatea.local) (80.142.118.100) by mail.gmx.net (mp026) with SMTP; 11 Jun 2003 01:02:16 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19Ps8M-000C4l-SM; Wed, 11 Jun 2003 01:02:30 +0200 Date: Wed, 11 Jun 2003 01:02:30 +0200 From: Thomas Moestl To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030610230230.GC734@crow.dom2ip.de> Mail-Followup-To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610223436.GC37257@funkthat.com> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 23:02:19 -0000 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 http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C