On Fri, Oct 31, 2008 at 11:25 AM, ron minnich rminnich@gmail.com wrote:
On Thu, Oct 30, 2008 at 8:08 AM, Myles Watson mylesgw@gmail.com wrote:
Is it a feature that the device scan depends on the order that the
devices
are listed in in the dts?
What I'm saying is that if you list the HT tunnel before the PCI bridge
you
get different results than if you list the bridge first. Is this by design? Is the dts supposed to be ordered as if it were a depth-first traversal of the devices, or is the device code supposed to be smart
enough
to find the devices as long as they are listed as the children of the correct parents?
I think it is a feature ... but the phase stuff is supposed to allow you to ensure ordering.
All right. I just wanted to make sure I understood the intent. I'm getting a lot closer. I can actually disable devices now.
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.
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!
I'm attaching a boot log, dts, and the patch to flattree.c
Thanks, Myles