dts general question

[Myles Watson]

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?

Thanks,
Myles

[ron minnich]

On Thu, Oct 30, 2008 at 8:08 AM, Myles Watson  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.

ron

[Myles Watson]

On Fri, Oct 31, 2008 at 11:25 AM, ron minnich  wrote:
> On Thu, Oct 30, 2008 at 8:08 AM, Myles Watson  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