Date: Wed, 21 Apr 1999 02:57:02 +0100 From: paul@originative.co.uk To: peter@netplex.com.au, dfr@nlsystems.com Cc: takawata@shidahara1.planet.sci.kobe-u.ac.jp, freebsd-current@freebsd.org Subject: RE: newbus and modem(s) Message-ID: <A6D02246E1ABD2119F5200C0F0303D10FEFD@octopus>
next in thread | raw e-mail | index | archive | help
> -----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. Paul. 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?A6D02246E1ABD2119F5200C0F0303D10FEFD>