Re: introduce device_is_attached()

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Tue, 17 Apr 2012, Christoph Egger wrote:

> On 04/16/12 19:37, David Young wrote:

> > I'm not sure I fully understand the purpose of amdnb_miscbus.
> > Are all of the functions that do/will attach at amdnb_miscbus
> > configuration-space only functions, or are they something else?  Please
> > explain what amdnb_miscbus is for.
> 
> Drivers attaching to amdnb_miscbus are all pci drivers which use
> different capabilities of the northbridge device.
> Their match/attach routines need the same 'aux' parameter as it
> is passed to amdnb_misc(4).
> 
> amdtemp(4) uses some PCI registers of the northbridge device to read
> the cpu temperature.
> I have a local driver which uses a different feature of the same
> northbridge device.
> To access the device I need the same chipset tag and pci tag.
> 
> Instead of making amdtemp(4) a mess I chose to implement different
> features in different small drivers.
> This also simplifies handling of erratas: If a feature doesn't work
> then just don't let match/attach the corresponding driver.

Oh that problem.  It's been what, ten years now and the design of our PCI 
attachment framework is still a giant pain that needs to be worked around.

I first suffered from this when I started working on the PCI code for 
SPARCs.  They run OFW, which should be used to probe and enumerate the PCI 
buses.  All the important information about device enumeration is encoded 
as properties on the OFW device tree, and that is what should be used to 
identify and attach drivers instead of probing the PCI config space 
registers directly.  Important interrupt routing information is encoded in 
the device tree which is not available from the PCI registers, so it is 
necessary to correlate OFW device nodes with PCI driver instances to make 
the machine work properly.  

Unfortunately, our PCI framework wants to take over all aspects of device 
identification and probing and it's very difficult for the PCI bus driver 
to manipulate attachment of or provide extra information to child devices. 
I wanted to go and rewrite all that stuff so it worked properly, but 
instead we ended up using all sorts of nasty mechanisms to pass 
information around behind the PCI framework's back.

As far as I'm concerned, device_is_attached*() is a hack to work around 
the inadequacies of certain bus frameworks.

Someone should give the PCI code an overhaul to allow the parent device to 
identify the contents of individual PCI slots control attachment of 
drivers there, similar to the way the SBus framwork operates.  That way 
you could keep track of each driver that attaches.

Eduardo