From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 04:56:56 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 772F937B401; Tue, 10 Jun 2003 04:56:56 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E46843FA3; Tue, 10 Jun 2003 04:56:55 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h5ABuOTh050211 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 10 Jun 2003 13:56:32 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h5ABuLOs060145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2003 13:56:21 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h5ABuL9F010731; Tue, 10 Jun 2003 13:56:21 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h5ABuF7E010730; Tue, 10 Jun 2003 13:56:15 +0200 (CEST) Date: Tue, 10 Jun 2003 13:56:15 +0200 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20030610115615.GB10527@cicely12.cicely.de> References: <20030609165838.32044@hydrogen.funkthat.com> <20030610022706.GI509@cicely12.cicely.de> <20030609210919.33379@hydrogen.funkthat.com> <20030609.224621.71095461.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030609.224621.71095461.imp@bsdimp.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-RELEASE alpha User-Agent: Mutt/1.5.4i cc: gurney_j@resnet.uoregon.edu cc: freebsd-current@freebsd.org cc: freebsd-sparc64@freebsd.org cc: gurney_j@efn.org cc: ticso@cicely.de Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de 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 11:56:56 -0000 On Mon, Jun 09, 2003 at 10:46:21PM -0600, M. Warner Losh wrote: > 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). No - it checks the mfdev flag before increasing pcifunchigh. > 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) s/0x80/PCIM_MFDEV/ Maybe we should add a PCIM_REGLAYOUT as well. > 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 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. > this is based on my limited understanding that function 0 shouldn't be > attached and function 1 should... -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de