<br><br><div class="gmail_quote">On Fri, Oct 31, 2008 at 11:25 AM, ron minnich <span dir="ltr"><<a href="mailto:rminnich@gmail.com">rminnich@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Thu, Oct 30, 2008 at 8:08 AM, Myles Watson <<a href="mailto:mylesgw@gmail.com">mylesgw@gmail.com</a>> wrote:<br>
> Is it a feature that the device scan depends on the order that the devices<br>
> are listed in in the dts?<br>
><br>
> What I'm saying is that if you list the HT tunnel before the PCI bridge you<br>
> get different results than if you list the bridge first.  Is this by<br>
> design?  Is the dts supposed to be ordered as if it were a depth-first<br>
> traversal of the devices, or is the device code supposed to be smart enough<br>
> to find the devices as long as they are listed as the children of the<br>
> correct parents?<br>
><br>
<br>
</div></div>I think it is a feature ... but the phase stuff is supposed to allow<br>
you to ensure ordering.</blockquote><div><br>All right.  I just wanted to make sure I understood the intent.  I'm getting a lot closer.  I can actually disable devices now.<br><br>One of the main problems is that the dts puts devfn numbers in the device structures, and those are used to match during phase 3.  Because the HT code collapses the enumeration, all HT devices need to have devfn == 0.  The HT code could do this, or we could add a ht@a.0 (that's the route I tried first) so that the devfn is 0 for HT devices.<br>
<br>The latest problem I have is the devfn getting corrupted for some devices.  If you look early in the device log, the devfn for 7_0 is the correct 0x38.  Later it is 0x68!<br><br>I'm attaching a boot log, dts, and the patch to flattree.c<br>
<br>Thanks,<br>Myles</div></div>