Messages in this thread | | | From | Grant Likely <> | Subject | Re: [PATCH v4 2/8] OF: Introduce DT overlay support. | Date | Wed, 14 May 2014 16:49:07 +0100 |
| |
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.
| |