Am 25.08.2014 15:08, schrieb Jon Loeliger:
Anyway, instead of going back and forth between "deferred probe is good"
and "deferred probe is bad", how about we do something useful now and
concentrate on how to make use of the information we have in DT with the
goal to reduce the number of cases where deferred probing is required?
Good idea.
The proposal on the table is to allow the probe code
to make a topological sort of the devices based on
dependency information either implied, explicitly stated
or both. That is likely a fundamentally correct approach.
I believe some of the issues that need to be resolved are:
1) What constitutes a dependency?
In my patches phandles are used. That works pretty good for almost all
DTs. So almost all dependencies are already declared in a DT and almost
no changes to the DT are necessary. The only binding I've seen where it
doesn't work is remote-endpoint, because that binding isn't a directed
dependency. So one of the two places where such a binding occurs needs a
"no-dependencies = <phandle>" to avoid circular dependencies which can
be solved.
2) How is that dependency expressed?
Already there in form of phandles.
3) How do we add missing dependencies?
My patches offer the possibility to extend or reduce the list of
(automatically generated) dependencies by using "[no-]dependencies = <
list of phandles >;"
4) Backward compatability problems.
None in my approach. The DT just includes an additional binding to
circumvent the missing but needed type information for phandles.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
