[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: introduce device_is_attached()
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.
Main Index |
Thread Index |