From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 9 21:47:42 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 8574A37B401; Mon, 9 Jun 2003 21:47:42 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0B0F43FBD; Mon, 9 Jun 2003 21:47:38 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h5A4lJkA007790; Mon, 9 Jun 2003 22:47:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 09 Jun 2003 22:46:21 -0600 (MDT) Message-Id: <20030609.224621.71095461.imp@bsdimp.com> To: gurney_j@resnet.uoregon.edu, gurney_j@efn.org From: "M. Warner Losh" In-Reply-To: <20030609210919.33379@hydrogen.funkthat.com> References: <20030609165838.32044@hydrogen.funkthat.com> <20030610022706.GI509@cicely12.cicely.de> <20030609210919.33379@hydrogen.funkthat.com> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: ticso@cicely.de cc: freebsd-sparc64@freebsd.org 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 04:47:42 -0000 In message: <20030609210919.33379@hydrogen.funkthat.com> John-Mark Gurney writes: : > > +#ifdef __sparc64__ : > > + /* : > > + * XXX - some sparc hardware has valid hardware when the : > > + * function 0 doesn't probe. Scan all functions. : > > + */ : > > + pcifunchigh = PCI_FUNCMAX; : > > +#else : > > pcifunchigh = 0; : > > +#endif : > > for (f = 0; f <= pcifunchigh; f++) { : > > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); : > > if (dinfo != NULL) { : > : > This is problematic as it ignores the fact about single function : > devices which may react to all function numbers. : : Wouldn't this happen with the current logic? since if function 0 is : found, it scans the rest... (Might be getting confused with SCSI : buses). Actually, there's no reason not to scan the hardware. we likely should be checking the multi function status differently than we are right now. We also shouldn't be rejecting based on the vendor id. while that provides a convenient way to chek to see if it really isn't there, a better sanity check would be to check the header type to see if it a one we know about (0, 1 or 2). If so, then we know if the device is there. that might be a better hueristic to see if we need to scan everything. : Actually, I was thinking that we could check to see if the next word : is not -1. The chip responds to the rest of the registers, but just : doesn't respond to the DEVVENDOR (first word). since header type is a required field, this likely is a better way to go. maybe keep the test against -1 for adding it as a child, but don't assume nothing is there unless the header type is bogus. : I'm also thinking of adding support code to the pci bus to let the : userland add a new device node to be probed. It shouldn't be too hard, : but would be help in these cases. I'd rather tht we fix the pci probe code to do the right thing. Kludges like this tend to live for a long time because nobody bothers to fix them correctly... I'm thinking that the loop should be more like: pcifunchigh = 0; f = 0; hdrtype = REG(PCIR_HEADERTYPE, 1); if (hdrtype & 0x7f > 2) continue; if (hdrtype & 0x80) pcifunchigh = PCI_FUNCMAX; for (f = 0; f <= pcifunchigh; f++) { dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); if (dinfo != NULL) pci_add_child(dev, dinfo); } might be better code (REG likely needs to be correctly defined for this context). this is based on my limited understanding that function 0 shouldn't be attached and function 1 should... Warner