Date: Mon, 19 Apr 1999 20:45:02 +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: <19990419124505.62D951F5E@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 19 Apr 1999 19:28:48 %2B0800." <19990419112851.17D6F1F5E@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote:
> Doug Rabson wrote:
> > On Mon, 19 Apr 1999, Takanori Watanabe wrote:
> >
> > > In message <Pine.BSF.4.05.9904190929070.85882-100000@herring.nlsystems.co
m>
> , Do
> > > ug Rabson wrote:
> > > >On Mon, 19 Apr 1999 takawata@shidahara1.planet.sci.kobe-u.ac.jp wrote:
> > > >> Simple Question.
> > > >> If there were 'Closed'-Host-Controller-Interface with object-only driv
er
> ,
> > > >> Can the vendor make the Host controller recognized without changing
> > > >> usb.c code?
> > > >>
> > > >> #That's what frustrated me while writing driver for smbus controller.
> > > >
> > > >It really depends on the nature of the bus. For plug-and-play style buss
es
> > > >such as USB and PCI, the controller can decide what devices exist withou
t
> > > >the help of drivers and can then uniquely match them with the right
> > > >driver. This trivially allows drivers to be added after the system is
> > > >running.
> > >
> > > I don't mention on upstream driver such as 'ukbd'
> > > (I think such device can be add truly dynamic),but I mention on
> > > 'host-controller' like [ou]hci.
> > >
> > > What I ask is what shall I do if there is a downstream driver without
> > > declared DRIVER_MODULE on upstream bus.Are there any way without changing
> > > upstream bus code?
> >
> > I don't think I understand. The DRIVER_MODULE declaration goes in the
> > downstream driver, not the upstream bus. The bus doesn't need any
> > knowledge of what drivers might be attached to it.
>
> Well, what about the i386 nexus? It specifically creates connection points
> for apm, npx, eisa, isa, and pci as children.
>
> However, pci devices don't do this to attach to their parent. I am
> obviously missing something. :-)
Never mind, I understand now. :-)
For the benefit of the 'cc' list, and to check my understanding, let me run
through it..
The parents pick up the children in one of two ways. For a 'smart' bus,
like pci, usb, eisa, etc, the bus probes itself and adds an "unidentified"
child (NULL name, -1 unit) with the known ID. The bus mechanism then uses
this to poll the drivers to see which one(s) want to claim that ID. It
knows who the children are because of the DECLARE_MODULE() statement. This
means that a "smart" (or self identifying) bus doesn't need anything more
to manage the relationship.
On the other hand, there's isa, which is quite dumb. In this case, the bus
looks up it's "hint" list and specifically adds the requested children from
those hints, and using the supplied irq, port, etc values from the hints.
The drivers then use that data to probe for the existance of the device.
The nexus is a little bit different.. It doesn't have things to
specifically look for, so it adds the children manually. It could have
used the resource database to find the requested things to attach to the
nexus in pretty much the same way as the isa bus does.
And then there's the old isa drivers... They attach themselves to the isa
parent device class on the fly, there is no DECLARE_MODULE() table for all
the old isa (and perhaps PCI too) drivers.
Doug, is that right so far? :-)
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.
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?19990419124505.62D951F5E>