On Mon, 19 Apr 1999, Peter Wemm wrote: > > > > > > I don't think I understand. The DRIVER_MODULE declaration goes in the > > > downstream driver, not the upstream bus. The bus doesn't need any > > > knowledge of what drivers might be attached to it. > > > > Well, what about the i386 nexus? It specifically creates connection points > > for apm, npx, eisa, isa, and pci as children. > > > > However, pci devices don't do this to attach to their parent. I am > > obviously missing something. :-) > > Never mind, I understand now. :-) > > For the benefit of the 'cc' list, and to check my understanding, let me run > through it.. > > The parents pick up the children in one of two ways. For a 'smart' bus, > like pci, usb, eisa, etc, the bus probes itself and adds an "unidentified" > child (NULL name, -1 unit) with the known ID. The bus mechanism then uses > this to poll the drivers to see which one(s) want to claim that ID. It > knows who the children are because of the DECLARE_MODULE() statement. This > means that a "smart" (or self identifying) bus doesn't need anything more > to manage the relationship. > > On the other hand, there's isa, which is quite dumb. In this case, the bus > looks up it's "hint" list and specifically adds the requested children from > those hints, and using the supplied irq, port, etc values from the hints. > The drivers then use that data to probe for the existance of the device. > > The nexus is a little bit different.. It doesn't have things to > specifically look for, so it adds the children manually. It could have > used the resource database to find the requested things to attach to the > nexus in pretty much the same way as the isa bus does. > > And then there's the old isa drivers... They attach themselves to the isa > parent device class on the fly, there is no DECLARE_MODULE() table for all > the old isa (and perhaps PCI too) drivers. > > Doug, is that right so far? :-)
Perfectly. > > Now what I'm curious about is how to handle the nexus and isa/eisa better > so they don't need to explicitly name the children. On one hand it could > look at the hints table to see all the 'at nexus?' declarations, but I > think it might be better to go for a hunt to locate all the children it can > find. One way to do this might be to simply add a heap of "unidentified" > devices and let the bus mechanism find all the devices that are children > and let them probe themselves while ignoring the fake device id's. Perhaps > this could change the probe order enough so that isa and eisa won't be > attached until after pci has been recursively probed. I'm not sure how this would work. At the nexus, I think it has to know what the possibly attached devices are (or at least a list of names). The NetBSD code does a simple probe (e.g. checking for pci config method or looking for the mainboard ID) before adding devices. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
