Date: Wed, 21 Apr 1999 04:19:38 +0800 From: Peter Wemm <peter@netplex.com.au> To: Doug Rabson <dfr@nlsystems.com> Cc: Takanori Watanabe <takawata@shidahara1.planet.sci.kobe-u.ac.jp>, freebsd-current@freebsd.org Subject: Re: newbus and modem(s) Message-ID: <19990420201939.A782C1F63@spinner.netplex.com.au> In-Reply-To: Your message of "Tue, 20 Apr 1999 09:14:32 %2B0100." <Pine.BSF.4.05.9904200910010.85882-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? :-) Cheers, -Peter 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?19990420201939.A782C1F63>