[RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
From: Alexander Holler <hidden>
Date: 2014-08-26 07:57:07
Also in:
linux-devicetree, lkml
Am 25.08.2014 15:08, schrieb Jon Loeliger:
quoted
quoted
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