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?

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.


Alexander Holler
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at