From owner-freebsd-arch@FreeBSD.ORG  Sat Aug 23 02:07:43 2008
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 AF7051065672;
	Sat, 23 Aug 2008 02:07:43 +0000 (UTC) (envelope-from imp@bsdimp.com)
Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85])
	by mx1.freebsd.org (Postfix) with ESMTP id 6CFC88FC16;
	Sat, 23 Aug 2008 02:07:43 +0000 (UTC) (envelope-from imp@bsdimp.com)
Received: from localhost (localhost [127.0.0.1])
	by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7N24d8S083859;
	Fri, 22 Aug 2008 20:04:39 -0600 (MDT) (envelope-from imp@bsdimp.com)
Date: Fri, 22 Aug 2008 20:05:11 -0600 (MDT)
Message-Id: <20080822.200511.1137957320.imp@bsdimp.com>
To: rpaulo@FreeBSD.org
From: "M. Warner Losh" <imp@bsdimp.com>
In-Reply-To: <20080823013912.GA19588@epsilon.local>
References: <20080822.160107.511563083.imp@bsdimp.com>
	<20080822225119.GA65119@onelab2.iet.unipi.it>
	<20080823013912.GA19588@epsilon.local>
X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: brooks@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org,
	freebsd-arch@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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Aug 2008 02:07:43 -0000

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);