Date: Tue, 20 Apr 1999 21:34:49 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Peter Wemm <peter@netplex.com.au> Cc: Takanori Watanabe <takawata@shidahara1.planet.sci.kobe-u.ac.jp>, freebsd-current@freebsd.org Subject: Re: newbus and modem(s) Message-ID: <Pine.BSF.4.05.9904202133120.85882-100000@herring.nlsystems.com> In-Reply-To: <19990420201939.A782C1F63@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Apr 1999, Peter Wemm wrote: > Doug Rabson wrote: > > On Mon, 19 Apr 1999, Peter Wemm wrote: > [..] > > > 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. > > Thinking about this some more, the same problem is applicable to "smart" > isa devices where the driver can find the card and the settings without > any help. Presently it won't even get probed unless there is an 'at isa?' > hint to cause the driver to be connected to isa. > > Presently, drivers are added to busses mostly in two ways. The first is > where the bus has identification, and each identifier is added listing > a device_id with an unknown driver/unit. The new-bus code will try all > of the registered child drivers in turn until it finds one that matches > and stops there. The isa bus on the other hand uses the hints to create > a device instance that needs verification/probing. If there's no hint, > the driver doesn't get a chance to probe. > > What I'd like would be for the busses to be able to call all the child > drivers to let them look for themselves, and not stop until all are probed. > For isa this would mean hint-less probing capabilities. For example, a > driver could know that the hardware lives at one of 4 IO port addresses, so > it could test them to see if it looks likely that there is one there. > > Obviously there is danger in this as calling the generic probe routines > with no hints at all (ie: all zero) will cause rather bad results on most > existing drivers. Perhaps there could be a specific 'identify' method for > drivers that support this. > > ie: the probe/attach sequence would become: > > bus identifies what it can, ie: find device id's or look up resource hints. > bus calls all child drivers to probe what has been found or hinted at > bus calls all child drivers with an identify methods to see if they can > find something on their own without an id or hint. > > This would be applicable to the nexus code as it would call all it's child > driver 'identify' methods which would cause them to attach themselves to > the nexus. You could then do a 'kldload eisa' and have the nexus get a > notification of a new driver added, and then in doing the normal probe of > the known devices (ie: none), the new eisa driver will have it's identify > called which could then cause a new instance to be attached to the nexus, > like what is presently hard coded. > > Does that make sense or am I rambling? :-) It certainly makes sense (it would be sort of like the old eisa code where the driver digs around and finds all of the devices which it can drive). I have to figure out how this fits in with the interface system which really needs a device to hang off. -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9904202133120.85882-100000>