On Wed, Aug 06, 2003 at 07:27:42PM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Bernd Walter <[EMAIL PROTECTED]> writes: > : The host bridge is not available yet at probing time of the host bridge. > : What we have is the host bridges parent (nexus) in the calling function. > : Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or > : we find it out later. > > Don't you mean legacy_pcib_is_host_bridge? That's where the matching
Yes - I looked at 5.1-RELEASE code. Layering seems to have been changed since then. > is done in current right now (well, at least as of my last sync) If > so, passing the host bridge's device down to it would be trivial to > add. It would also allow other CPUs with builtin host bridges to do How? legacy_pcib_is_host_bridge is called before BUS_ADD_CHILD. > similar tricks to the one that is done for the ELAN. These sorts of > features have been very common in other CPU families, and there's no > reason to think that there won't be more of them in the x86 family as > time goes on. point taken. > I'm not sure that adding it to nexus at this stage of the boot would > truly work. Since the legacy device has decided to attach, the nexus > bus is already walking through its children. Adding a child during > that walk strikes me as dangerous, since we have no locking on the > children element of the device_t. Hmmm, looks I just found a source > of problems in my newbus locking code that might explain some weird > things happening when I enable it.... Thanks for making me go look :-) OK - that's an argument to avoid nexus. -- B.Walter BWCT http://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"