On 05/02/18 09:06, Phil Elwell wrote: > Rob, > > On 02/05/2018 16:49, 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. > > The case I've encountered is the "non-removable" flag on an SD interface, specifically > the SD interface used for an SDIO link to a WiFi chip on the Raspberry Pi 3B, which is > marked "non-removable" for operational reasons. Some users prefer to repurpose the SD > interface to drive a second SD card on a different set of pins, which they could do using > an overlay except for the "non-removable". The ugly workaround is to disable the original > interface node and create a near-clone in the overlay without the unwanted property. > >> 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? > > I agree that deletion of a property at run-time could prove awkward - if only booleans > were implemented another way - but a non-run-time restriction wouldn't bother me since > we can require users to only apply the overlay via the firmware. > > Since writing the original email I've thought some more about the implementation, and > perhaps a new tag is too disruptive a change. An alternative implementation would be to > create a new node, in the same vein as "__symbols__", listing properties to delete in > some suitable encoding. The more I think about trying to encode property deletion in a separate section, apart from the overlay fragment where the property is intended to be deleted, the more I envision corner cases where the result of applying the overlay is ambiguous or incorrect. Unfortunately trying to describe any of the issues will result in me writing a novel's worth of text, so I would rather avoid that. > > 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 > -- 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
