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: 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
