From owner-freebsd-current@FreeBSD.ORG Tue Oct 4 15:48:58 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2068E16A420 for ; Tue, 4 Oct 2005 15:48:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0D7543D45 for ; Tue, 4 Oct 2005 15:48:57 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j94FmG8m007952; Tue, 4 Oct 2005 09:48:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 04 Oct 2005 09:49:05 -0600 (MDT) Message-Id: <20051004.094905.112627036.imp@bsdimp.com> To: fli@shapeshifter.se From: "M. Warner Losh" In-Reply-To: <43424F75.3000409@shapeshifter.se> References: <4341A55B.1070209@shapeshifter.se> <20051003.165337.14303305.imp@bsdimp.com> <43424F75.3000409@shapeshifter.se> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 04 Oct 2005 09:48:24 -0600 (MDT) Cc: benlutz@datacomm.ch, current@freebsd.org Subject: Re: Linksys EG1032 rev. 3 patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2005 15:48:58 -0000 In message: <43424F75.3000409@shapeshifter.se> Fredrik Lindberg writes: : M. Warner Losh wrote: : > In message: <4341A55B.1070209@shapeshifter.se> : > Fredrik Lindberg writes: : > : Filtering on subvendor/subdevice might be better, I didn't even think : > : of that and revision filtering seemed to be quite popular among : > : exsisting drivers. : > : > Yes. Many chip vendors bump the revision field 'often'. Just how : > often varies from chip maker to chip maker. Some do only when they : > have a new version of the chip that needs special work arounds (or : > that no longer needs them :-). Others do change it for each change to : > the silicon. Most are somewhere inbetween. : > : > : The subdevice id for a rev.3 card seems to be 0x0024 (subvendor 0x1737). : > : I don't own a rev. 2 card but google says that the rev.2 card has : > : subdevice id 0x0015 (subvendor 0x1737). : > : > That might be sufficient... : > : : Ok, how should this be implemented then? Just a specific check in each : drivers probe methods or by adding some svid/sdid fields to : struct rl_type and similar structs. : I would go for the latter, but that might be overkill. I'd code it as a special case in re and sk driver's probe routine for the moment. If more of these cards surface, then doing something more general might be a good idea. Warner