On 05/03/18 04:31, Phil Elwell wrote: > David, > > On 03/05/2018 03:22, David Gibson wrote: >> On Wed, May 02, 2018 at 05:06:06PM +0100, 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. >> >> That has the advantage(?) of not actively breaking things that don't >> understand the new tag. The reason I question whether that's an >> advantage is that things that didn't understand the new encoding still >> obviously wouldn't be able to process the deletion. So the question >> is whether silently ignoring the delete is better or worse than >> blowing up entirely when given an fdt with the new deletion encoding. > > Since the overlay doesn't know the state of the base DTB it is being applied to, there I beg to differ. An overlay and the base DTB it is applied to are not independent objects. An overlay has to apply to a "known base". This might not be quite as strict as it sounds. For example, two different base DTBs might include a .dtsi that defines node "A". It may be reasonable for an overlay to create a sub-node (path .../A/B) such that the overlay can cleanly be applied on top of either base DTB. > are going to be cases where overlays attempt to delete non-existent properties, which is > harmless with one encoding and fatal (at least for that overlay) in the other. I don't > have a strong opinion on the matter - it's not a big issue on the Pi where we usually > update kernel, firmware and DTB together - but confining the required changes to the > overlay generation and application code seems preferable. > > 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
