From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 30 00:04:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C10D116A4CF for ; Thu, 30 Sep 2004 00:04:07 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BDE243D39 for ; Thu, 30 Sep 2004 00:04:07 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8U017Cr021973; Wed, 29 Sep 2004 18:01:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 29 Sep 2004 18:02:27 -0600 (MDT) Message-Id: <20040929.180227.22551443.imp@bsdimp.com> To: bcg@intelli7.com From: "M. Warner Losh" In-Reply-To: <1096485467.2670.1127.camel@localhost.localdomain> References: <1096476707.2670.1088.camel@localhost.localdomain> <415AF2D0.7090002@pantasys.com> <1096485467.2670.1127.camel@localhost.localdomain> X-Mailer: Mew version 3.3 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-hackers@freebsd.org cc: peter@pantasys.com Subject: Re: Device probe issue with an em(4) compatible device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2004 00:04:07 -0000 In message: <1096485467.2670.1127.camel@localhost.localdomain> Brenden Grace writes: : On Wed, 2004-09-29 at 13:37, Peter Buckingham wrote: : > why compile the em driver in at all? it won't probe the device if it : > doesn't exist ;-) : : because I need it ... As opposed to just hacking the em driver? : > otherwise, just add some code to the em's probe routine to check for : > your subvendor, subdevice pair and exit without attaching. : : Well sure (though ugly), but I think having it just return a negative : number would be a better fix than that. I was more interested in why the : em driver (and others) returns 0 and ends the probing of a device that : it could possibly only partially support (based on its matching of : PCI_ANY_ID). If I understand DEVICE_PROBE(9) correctly it seems that the : whole reason for the negative return scale is to avoid this very issue. That's correct. PCI_ANY_ID has nothing to do with it. If em_probe returns 0, it trumps all other drivers for that device that haven't had a chance to bid (as well as the potential drivers that bid a negative number). Warner