How to get a device_t

[Bernd Walter]

On Wed, Aug 06, 2003 at 07:27:42PM -0600, M. Warner Losh wrote:
> In message: <20030807005810.GG35859 at cicely12.cicely.de>
>             Bernd Walter <ticso at cicely12.cicely.de> 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
ticso at bwct.de                                  info at bwct.de