From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 03:32:24 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B49131065677; Sat, 23 Aug 2008 03:32:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF568FC1B; Sat, 23 Aug 2008 03:32:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [IPv6:2001:470:1f11:75:2a0:d2ff:fe18:8b38]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7N3WFuu010991; Fri, 22 Aug 2008 23:32:15 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 22 Aug 2008 22:41:51 -0400 User-Agent: KMail/1.9.7 References: <20080822.160107.511563083.imp@bsdimp.com> <20080823013912.GA19588@epsilon.local> <20080822.200511.1137957320.imp@bsdimp.com> In-Reply-To: <20080822.200511.1137957320.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808222241.52325.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:2001:470:1f11:75::1]); Fri, 22 Aug 2008 23:32:15 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8076/Fri Aug 22 18:15:54 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: brueffer@freebsd.org, brooks@freebsd.org, rpaulo@freebsd.org, ivoras@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 03:32:24 -0000 On Friday 22 August 2008 10:05:11 pm M. Warner Losh wrote: > In message: <20080823013912.GA19588@epsilon.local> > > : I hope this is what Warner was trying to say. > > More or less the following, with a less lame way of getting the table > into the kernel, and maybe more fields than vendor/device.... > > The reason this works is that the pci_get_vendor and pci_get_device > read out of the area pointed to by cfg. > > Warner > > Index: pci.c > =================================================================== > --- pci.c (revision 182024) > +++ pci.c (working copy) > @@ -419,6 +419,33 @@ > #undef REG > } > > +static struct pci_remap_entry > +{ > + uint16_t vendor; > + uint16_t device; > + uint16_t mapped_vendor; > + uint16_t mapped_device; > +} pci_remap[] = > +{ > + { 0x1039, 0x0901, 0x1039, 0x0900 } /* Map sis 901 to sis 900 */ > +}; > +static int pci_remap_entries = 1; > + > +static void > +pci_apply_remap_table(pcicfgregs *cfg) > +{ > + int i; > + > + for (i = 0; i < pci_remap_entries; i++) { > + if (cfg->vendor == pci_remap[i].vendor && > + cfg->device == pci_remap[i].device) { > + cfg->vendor = pci_remap[i].mapped_vendor; > + cfg->device = pci_remap[i].mapped_device; > + return; > + } > + } > +} > + > /* read configuration header into pcicfgregs structure */ > struct pci_devinfo * > pci_read_device(device_t pcib, int d, int b, int s, int f, size_t size) > @@ -465,6 +492,7 @@ > > pci_fixancient(cfg); > pci_hdrtypedata(pcib, b, s, f, cfg); > + pci_apply_remap_table(cfg); > > if (REG(PCIR_STATUS, 2) & PCIM_STATUS_CAPPRESENT) > pci_read_extcap(pcib, cfg); It might be nice to drive it by hints so users can tweak it on the fly. Maybe something like: hint.pci0...vendor=XXXXX Then users can simply add entries to /boot/loader.conf w/o needing any recompiles for new device IDs that the driver can handle using an existing device id. The lookup table you have still requires patching source somewhere which probably defeats the purpose. -- John Baldwin