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>