On 05/03/18 05:54, Phil Elwell wrote: > 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 disagree with the characterization of "harmless". A silent ignoring of the encoding means that the overlay is _incorrectly_ applied. This is a _bug_. -Frank > >>> 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
