Date: Tue, 13 Jun 2000 10:57:10 -0700 From: Mike Smith <msmith@freebsd.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Mike Smith <msmith@FreeBSD.ORG>, Terry Lambert <tlambert@primenet.com>, arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h Message-ID: <200006131757.KAA22609@mass.cdrom.com> In-Reply-To: Your message of "Tue, 13 Jun 2000 19:37:01 %2B0200." <11712.960917821@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <200006131734.KAA22492@mass.cdrom.com>, Mike Smith writes: > > >> The PCI issue is unique, in that PCI devices can be identified by > >> a generic routine. > > And case in point: Just because you have identified a PCI chip > doesn't mean that you know what's next to it on the board. > > The AMCC "PCI Matchmaker" is a very good example. > > (If you know what this chip is, search ebay for "pci matchmaker" :-) I've designed hardware using this device (and similar from PLX). In each case, you stuff your new PCI IDs into the EEPROM. More importantly, to comply with PCI 2.1, which is required for the Windows Logo Program, you *have* to have a unique ID. IOW, there is a niche for detecting "bad" hardware, but assuming that it's the default case isn't really a good idea. And in the worst case, you have a small handful of drivers registered and loaded for the 'generic' ID, and each of their probe routines gets a shot at the device. So what? The end result is a loaded and functional driver. As I've said, and keep saying, these are all issues that we've _already_ trampled flat into the mud. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006131757.KAA22609>