Re: [RFC PATCH 1/9] dt: deps: dtc: Automatically add new property 'dependencies' which contains a list of referenced phandles

[Alexander Holler]

Am 19.05.2014 17:49, schrieb Jon Loeliger:
> [ Crap.  Sorry about the duplicate post.  Stupid HTML; didn't hit the
> lists. -- jdl ]
>
>
> > What's still questionable about the patches for dtc is if dependencies to
> > devices and not just drivers should be included in the new property
> > dependencies too.
>
> I don't think the DTC should have any semantic knowledge of why these
> dependency arcs are being added to the graph.  Sure, it could be that
> different types of arcs are added, and that the total dependency graph
> travels multiple such arc types to obtains some valid topological sort,
> but the DTC itself should just not care.

I will remove those policies (which means including all dependencies). 
As said below, I already thought it was evil premature optimization (I 
did in order to make the graph a bit smaller and to save some bytes). 
(No date, it isn't a paid project so I will do it whenever I feel good 
to do so).

> After saying that, there are likely semantic checks that could be added to
> ensure some policy about those arcs was followed.  Separate the
> implementation from the policy.  There is already plenty of discussion
> down that line within the DTC ongoing.

Hmm, discussion about what? Those dependencies or about semantic checks?

Btw., if someone has a problem with the necessary time to do the 
topological sort at boot time (needs a few ms on a single core omap with 
600 MHz), there could be an additional option to add a new property 
which includes the whole (already topological sorted) list. That 
wouldn't be much effort. But currently I don't think any DT enabled 
device is in need of having to avoid doing the topological sort itself.

Regards,

Alexander Holler

> HTH,
> jdl
>
>
> On Mon, May 19, 2014 at 7:35 AM, Alexander Holler <holler@xxxxxxxxxxxxx>wrote:
>
> > Am 17.05.2014 14:16, schrieb Tomasz Figa:
> >
> >
> >   References to phandles of parent or child nodes will not be added to this
> > > > property, because this information is already contained in the blob (in
> > > > the
> > > > form of the tree itself).
> > >
> > > I wonder if we shouldn't be including them too for consistency related
> > > reasons, so we have all the necessary information in one place.
> > > References to child nodes are great recipes for cycles, though...
> > >
> > > No strong opinion, though, just an idea.
> >
> > As said, they are already in the tree itself. And they are already
> > included in the graph (these are the black edges), so they just don't
> > appear in the property dependencies.
> >
> >
> >
> > > > No dependencies to disabled nodes will be added.
> > > Same here. IMHO it might be wise to let the parsing entity (e.g. kernel)
> > > decide whether to ignore a dependency to disabled node or not.
> > >
> > > Otherwise, I like the simplicity of compile-time dependency list
> > > creation. Quite a nice work.
> >
> > Thanks.
> >
> > What's still questionable about the patches for dtc is if dependencies to
> > devices and not just drivers should be included in the new property
> > dependencies too. My current assumption is that all devices belonging to
> > one and the same driver don't have dependencies between each other. In
> > other words the order in which devices will be attached to one and the same
> > driver isn't important. If that assumption is correct it would be possible
> > to just attach all devices belonging to a driver after the driver was
> > loaded (also I haven't that done in my patches).
> >
> > And thinking about that again, I think I was wrong and doing so have been
> > some kind of evil premature optimization I did in order to spare a few
> > dependencies/edges. But changing this can done by removing a few lines in
> > the code for dtc (patch 1).
> >
> > Regards,
> >
> > Alexander Holler
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
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/