Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
From: Alexander Holler
Date: Tue Aug 26 2014 - 03:57:10 EST
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?
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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/