From owner-freebsd-current Tue Apr 20 1:13:46 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 308D414F46 for ; Tue, 20 Apr 1999 01:13:42 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA94478; Tue, 20 Apr 1999 09:14:32 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 20 Apr 1999 09:14:32 +0100 (BST) From: Doug Rabson To: Peter Wemm Cc: Takanori Watanabe , freebsd-current@freebsd.org Subject: Re: newbus and modem(s) In-Reply-To: <19990419124505.62D951F5E@spinner.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message