Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 May 1999 09:40:57 +0100 (BST)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Julian Elischer <julian@whistle.com>
Cc:        hackers@freebsd.org
Subject:   Re: Slight suggested change to PCI config stuff.
Message-ID:  <Pine.BSF.4.05.9905070938490.411-100000@herring.nlsystems.com>
In-Reply-To: <3732725E.2781E494@whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905070938490.411-100000>