Date: Wed, 29 Sep 2004 18:06:55 -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.180655.29463294.imp@bsdimp.com> In-Reply-To: <1096487538.2670.1147.camel@localhost.localdomain> References: <1096485467.2670.1127.camel@localhost.localdomain> <415B0DDA.2040200@pantasys.com> <1096487538.2670.1147.camel@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <1096487538.2670.1147.camel@localhost.localdomain>
Brenden Grace <bcg@intelli7.com> writes:
: On Wed, 2004-09-29 at 15:32, Peter Buckingham wrote:
: > experience then just not compiling in the em driver or an ugly like i
: > describe (or you suggest) should be fine.
:
: I wasn't trying to be rude, but DEVICE_PROBE(9) seems to describe how
: conflicts like this should be handled. I was wondering if I am in fact
: correct that devices that attempt to be generic enough for wide support
: (accepting PCI_ANY_ID) should also properly pass the probing (by
: returning some negative) so that a driver that may better fit the exact
: device can attach.
Well, it does match on the VENDOR ID and DEVICE, so it isn't that
generic. The subvendor field is generally a don't care field for
drivers in FreeBSD, so it is just following existing practices. Maybe
that practice should be revisited, but that's why em_probe does things
the way it does.
If you need em to not attach, you'll have to hack em in your tree to
return some small negative number.
Chances are excellent that FreeBSD 6 will have facilities to address
these issues (they are needed both for 'vendor supplied updated
drivers' as well as 'please load me when you see this sort of card').
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040929.180655.29463294.imp>