On Wed, 2018-05-02 at 10:49 -0500, Rob Herring wrote: > On Wed, May 2, 2018 at 4:19 AM, Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote: > > > > David et al., > > > > I've mentioned before the problem posed for overlays by boolean properties, i.e. > > that a boolean property that is "true" in a base DTB cannot be made "false" by an > > overlay because doing so requires that the property be deleted. A solution for this > > problem would be to define a new FDT tag - FDT_DEL_PROP, say - that is used to encode > > any /delete-property/ found in a node during overlay compilation. When the overlay is > > applied, the named property would be deleted if present. > > > > A heuristic would be needed to decide whether this property should be encoded or just > > acted on immediately - the use of the '-@' command line parameter would seem to fit the > > bill. > > > > Although one might consider extending this mechanism to cover node deletion, in practice > > I think this would be too problematic in terms of broken phandle references etc., and in > > most cases 'status = "disabled"' achieves the same objective, so I'm not proposing this > > be added. > > > > Is such a change something you would consider supporting, or do you have an alternative > > preferred solution? > Can you give some examples of cases where you need this feature. > > I'm concerned about how an OS is supposed to deal with properties > disappearing. Do we need to start refcounting properties too? That's > not really a reason to not support this in dtc, but rather perhaps a > policy decision in the OS to not delete properties once a node is in > use/active. Would such a policy break your use case? > > Rob How is an in-use property being deleted at runtime different than the value assigned to an in-use property being changed at runtime? Likewise for adding a boolean property to an in-use node at runtime, that could have exactly the same type of operational impact as deleting a boolean would have. Why would a different policy or handling for those cases be needed? -- Ian -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
