Date: Wed, 29 Sep 2004 18:02:27 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: bcg@intelli7.com Cc: peter@pantasys.com Subject: Re: Device probe issue with an em(4) compatible device Message-ID: <20040929.180227.22551443.imp@bsdimp.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <1096485467.2670.1127.camel@localhost.localdomain> Brenden Grace <bcg@intelli7.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040929.180227.22551443.imp>