How to get a device_t

[John Baldwin]

On 07-Aug-2003 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
> 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
> 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.
> 
> 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 :-)

You would add it to legacy, not nexus.  What you probably really want
to do is to write a host-PCI bridge driver that attaches to the actual
PCI device like 'hostb' and 'agp' do that creates a suitable child bus
for the MMCR stuff.  This works for both ACPI and non-ACPI and doesn't
require hacking the legacy_pcib stuff.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/