From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 16:43: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 CC33E37B404; Tue, 10 Jun 2003 16:43:19 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0E5643FBD; Tue, 10 Jun 2003 16:43:17 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5ANXxZM011114; Tue, 10 Jun 2003 19:34:00 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5ANfiev040296; Tue, 10 Jun 2003 16:41:44 -0700 (PDT) (envelope-from jmg) Date: Tue, 10 Jun 2003 16:41:44 -0700 From: John-Mark Gurney To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030610234144.GA39701@funkthat.com> 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> <20030610230230.GC734@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <20030610230230.GC734@crow.dom2ip.de> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney 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:43:20 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: > On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote: > > > > Ok, attached is a patched I tried, > > Hmmm, you seem to have forgotten to actually attach it. Ok, this time I'll 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 :) Ok, right now in order to get the machine back up and functional I did remove the reg == 0, and running scanning all the functions. > 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 :) Yikes, I just started looking at the acpi code, and there's a lot of code in it! > > 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. Ok, the only problem is that is then we have the same problem the ACPI code does in that hot swapping cards would have a problem. Since it appears to me that the OFW tree doesn't get updated upon a swap. (At least the usb part of the tree doesn't.) Does this mean that we should eliminate most of the Sun specific pci bus drivers in favor of OFW specific ones like ACPI? or? Thanks, I have plenty of time to hack on this right now, so any pointers would be useful. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pci.patch" Index: pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.214 diff -u -r1.214 pci.c --- pci.c 2003/04/16 03:15:08 1.214 +++ pci.c 2003/06/10 21:40:16 @@ -816,25 +816,32 @@ void pci_add_children(device_t dev, int busno, size_t dinfo_size) { +#define REG(n, w) PCIB_READ_CONFIG(pcib, busno, s, f, n, w) device_t pcib = device_get_parent(dev); struct pci_devinfo *dinfo; int maxslots; int s, f, pcifunchigh; + u_int8_t hdrtype; KASSERT(dinfo_size >= sizeof(struct pci_devinfo), ("dinfo_size too small")); maxslots = PCIB_MAXSLOTS(pcib); for (s = 0; s <= maxslots; s++) { pcifunchigh = 0; + f = 0; + hdrtype = REG(PCIR_HEADERTYPE, 1); + if ((hdrtype & ~PCIM_MFDEV) > 2) + continue; + if (hdrtype & PCIM_MFDEV) + pcifunchigh = PCI_FUNCMAX; for (f = 0; f <= pcifunchigh; f++) { dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); if (dinfo != NULL) { - if (dinfo->cfg.mfdev) - pcifunchigh = PCI_FUNCMAX; pci_add_child(dev, dinfo); } } } +#undef REG } void Index: pci_user.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci_user.c,v retrieving revision 1.9 diff -u -r1.9 pci_user.c --- pci_user.c 2003/03/03 12:15:44 1.9 +++ pci_user.c 2003/06/10 21:40:16 @@ -176,9 +176,8 @@ const char *name; int error; - if (!(flag & FWRITE)) + if (!(flag & FWRITE) && cmd == PCIOCWRITE) return EPERM; - switch(cmd) { case PCIOCGETCONF: --PEIAKu/WMn1b1Hv9--