From owner-freebsd-current@FreeBSD.ORG Mon Oct 3 19:28:11 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 4F7DD16A41F for ; Mon, 3 Oct 2005 19:28:11 +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 E159B43D49 for ; Mon, 3 Oct 2005 19:28:10 +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 j93JPjsT094537; Mon, 3 Oct 2005 13:25:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 03 Oct 2005 13:26:34 -0600 (MDT) Message-Id: <20051003.132634.20912224.imp@bsdimp.com> To: fli+freebsd-current@shapeshifter.se From: "M. Warner Losh" In-Reply-To: <433FB9B9.9020207@shapeshifter.se> References: <433F6018.2050900@datacomm.ch> <433F976F.6090501@samsco.org> <433FB9B9.9020207@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]); Mon, 03 Oct 2005 13:25:52 -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: Mon, 03 Oct 2005 19:28:11 -0000 Is rev the right thing to filter based on, or is the subvendor id and subvendor device? if a vendor sets the vendor id/vendor device fields wrong, who is to say that we can know based on the pci revision field if this device is right or not. The revision field tends to change a lot and having a sample size of 1 or 2 (or even 5) likely is insufficient to know if it can be relied upon to not cause problems with the next container load of the cards arrives... I know that the re vs rl decision is made based on the revision in the device's I/O space right now: while (t->rl_name != NULL) { if ((pci_get_vendor(dev) == t->rl_vid) && (pci_get_device(dev) == t->rl_did)) { ... map I/O hwrev = CSR_READ_4(sc, RL_TXCFG) & RL_TXCFG_HWREV; ... unmap I/O if (t->rl_basetype == hwrev) { device_set_desc(dev, t->rl_name); return (BUS_PROBE_DEFAULT); } } t++; } return (ENXIO); Checking for 0x10 vs 0x15 for a card that has gone from rev 2 to rev 3 just strikes me as unwise. Warner