On 03/05/2018 13:27, David Gibson wrote: > On Thu, May 03, 2018 at 12:31:24PM +0100, 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 >> 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. > > Nonsense. With any new encoding we get to define the semantics, so > either way we can make deleting a non-existent property a no-op rather > than an error. I think you've misunderstood my point. Adding a FDT_DEL_PROP tag for a deleted property will render that overlay incompatible with old tools- the "fatal" case - whereas a new "__delete__" node would be ignored by old tools - the "harmless" case. Obviously we get to define semantics with new tools, but for old tools we have to choose the encoding to get the desired behaviour. >> 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
