On Wed, May 2, 2018 at 11:12 AM, Ian Lepore <ian@xxxxxxxxxxx> wrote: > 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? It's not any different. We don't have a policy for any of it in Linux ATM other than any overlay support that gets added will need to consider these issues. Rob -- 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
