Re: "Early" devices and the DT

["glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org" <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:

>Some solutions to the early device problem
>
>a) Most complex:  Use new properties to create a dependency graph. 
>This 
>is probably the most general solution, but also probably the hardest
>for 
>people to think about and maintain.
>
>b) Define a set of init phases 0,1,2,...  and mark each early device 
>node with a phase number property.  Scan the tree for each phase and 
>handle only the devices with that phase number.  Unmarked nodes are 
>handled last.
>
>c) Similar to b, but instead of properties in nodes, have properties 
>like "linux-phase0", "linux-phase1", etc in /chosen, whose values are 
>lists of phandles.

d) don't try to encode init order at all in the DT, and let device drivers request probe to be deferred.  If this works out, it will be by far the least complex and won't require anybody to sit and work out the init order for each machine.  I've even already posted a draft patch to do this.

e) work out probe order dynamically by looking at known phandle types at device registration time. This is potentially more 'efficient' than option d, but it requires a lot of knowledge to be built into the registration code which will get really complex in a hurry.

Right now I'm strongly leaning in the direction of option d.

g.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.