From owner-freebsd-hackers Thu May 6 22: 0: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id B2C1214CA3 for ; Thu, 6 May 1999 22:00:05 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id VAA48831 for ; Thu, 6 May 1999 21:56:00 -0700 (PDT) Message-ID: <3732725E.2781E494@whistle.com> Date: Thu, 06 May 1999 21:55:58 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.8-STABLE i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Slight suggested change to PCI config stuff. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The PCI probe routines for chipset_probe() are called while the PCI code is traversing the linker set of loaded drivers. However it will catch any 'generic' bridge devices. Thus if the user has linked in a specific driver for a particular bridge device, it may not be called as the generic code may get there first. I propose to change the several places that traverse the linker set so that the 'chipset' default code is either skipped and called last, or, not put in the linker set, but rather called directly after the linker set has failed to find the correct driver. I want to do this so that I may load a specific driver to handle some of the features that are not normally set up in some of these chipsets, and that the generic code doesn't know about, due to their 'local' nature. For example, some of the Bridge chips have such things as GPIO pins that can be controlled from the control registers of the chipset. Obviously only a platform specific driver can know what those IO pins are attached to (e.g. power sensing. or an I2C bus.) These pins are changed by doing PCI config-space writes to the chipset, so should be controlled by that driver. Allowing a more specific driver to over-ride the generic default driver would seem to be the clean way to do this.. Any comments? (this is in 3.x but I presume the same makes sense in 4.x) julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message