On Wed, 14 May 2014 14:11:52 +0200, Michael Stickel <ms@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
