From owner-freebsd-hackers Fri May 7 1:40:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id C431E15CC6 for ; Fri, 7 May 1999 01:40:46 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA10089; Fri, 7 May 1999 09:40:57 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 7 May 1999 09:40:57 +0100 (BST) From: Doug Rabson To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: Slight suggested change to PCI config stuff. In-Reply-To: <3732725E.2781E494@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 6 May 1999, Julian Elischer wrote: > 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) This makes sense for 3.x. Everything is different for 4.x though post new-bus. The right think in 4.x is to use priority ordered probes (which I have working but haven't committed). If a driver matches the generic class it would return a lower priority than a driver which matches the device exactly. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message