Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

[Grant Likely <grant.likely@secretlab.ca>]

On Wed, 14 May 2014 14:11:52 +0200, Michael Stickel <ms@mycable.de> wrote:
> Hi Grant,
> 
> Am 14.05.2014 12:08, schrieb Grant Likely:
> > More generally I am concerned about whether or not overlays
> > will introduce corner cases that can never be handled correctly,
> > particularly in how multiple overlays will get handled. I want to see
> > very clear rules on what happens when multiple overlays are applied, and
> > then removed again. Is it possible to remove overlays out of order? If
> > so, what are the conditions that would not be allowed?
> 
> Yes, it is possible that an overlay depends on another.
> 
> The problem is not, that an overlay is removed other overlays depend on,
> but that nodes of an overlay may depend on the to-be-removed overlay and
> the resulting devicetree can become inconsistent.

So what should the rule be then? It sounds to me that it should be a
hard and fast rule for overlays to always be removed in-order. If two
overlays are applied, and the first one needs to be removed again, then
that forces a removal of the second. The code needs to enforce it too.

The question can be revisited if someone can find a way to validate
overlays do not conflict.

g.