[RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)

[Alexander Holler]

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