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
