Ian, On 02/05/2018 17:12, Ian Lepore 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? Because property values can be retrieved by reference, which would be left dangling in the event the property was deleted. Phil -- 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
