Date: Wed, 21 Apr 1999 09:12:24 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: paul@originative.co.uk Cc: peter@netplex.com.au, takawata@shidahara1.planet.sci.kobe-u.ac.jp, freebsd-current@freebsd.org Subject: RE: newbus and modem(s) Message-ID: <Pine.BSF.4.05.9904210910250.85882-100000@herring.nlsystems.com> In-Reply-To: <A6D02246E1ABD2119F5200C0F0303D10FEFD@octopus>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Apr 1999 paul@originative.co.uk wrote: > > -----Original Message----- > > From: Peter Wemm [mailto:peter@netplex.com.au] > > Sent: 20 April 1999 21:20 > > To: Doug Rabson > > Cc: Takanori Watanabe; freebsd-current@freebsd.org > > Subject: Re: newbus and modem(s) > > > > > > 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. > > Doesn't this get in to the area we discussed some time back on the new-bus > list about changing the way probing works so that instead of the pci code > calling all the device drivers it just looks the device id up in a table and > assigns that driver? > > I much prefer that direction than having all drivers called. > > > 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. > > If I'm reading this right then you'd call an identify function in all > available isa drivers and have them try and identify hardware? The risk here > is that isa drivers/devices don't play well together and will trash you're > machine if asked to probe for hardware that isn't present. If we do this, possible it should be restricted to 'wildcard' style declarations in the probe hints. -- 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.9904210910250.85882-100000>