Hi Sebastian, On May 26, 2014, at 6:09 PM, Sebastian Reichel wrote: > Hi, > > On Mon, May 26, 2014 at 02:55:37PM +0300, Pantelis Antoniou wrote: >> On May 26, 2014, at 2:23 PM, Grant Likely wrote: >>> On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: >>> Heeheehee. We're back where we started. The original question is whether >>> or not that is a valid approach. If the overlay represents something >>> that can be hot plugged/unplugged, then passing it through to the second >>> kernel would be the wrong thing to do. If it was a permenant addition, >>> then it probably doesn't need to be removed. >>> >>> We do actually keep the overlay info in memory for the purpose of >>> removal exactly so we can support hot unbinding of devices and drivers >>> that make use of overlays. >> >> We can support either method. I am not feeling any wiser about which one should be >> the default TBH, so what about exporting a property and let the platform >> figure out which is more appropriate? > > What about supporting "negative" overlays (so an overlay, that > removes DT entries)? That way one could reverse apply an overlay. > All the dependency stuff would basically be the users problem. The > kernel only checks if it can apply an overlay (and return some error > code if it can't). This this code is needed anyway to check the > input from userspace. > > As a result the overlay handling would basically have the same > behaviour as diff and patch :) > This is already supported; nodes and properties can be prefixed with a minus sign '-' and operate as expected :) i.e. "-property;" removes a property and "-node { };" removes a node. > P.S.: Sorry if this has already been suggested. I have only read > mails from PATCHv4. > > -- Sebastian Regards -- Pantelis -- 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