On Wed, May 2, 2018 at 3:33 PM, Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote: > On 02/05/2018 17: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 haven't gone to look what non-removable implies exactly (forces a card detect IIRC), but seems like non-removable should only be needed if you have a non-removable device *and* that device is not described in DT. IOW, a child device in DT should imply the device is non-removable. >>> I'm concerned about how an OS is supposed to deal with properties >>> disappearing. Do we need to start fcounting 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. Yes, that's a viable alternative and easier to deal with than a FDT format change. > A third approach, simpler still, is to allow an alternative encoding of a > boolean property, > only to be used when deleting a boolean using an overlay. That encoding > could be a > zero-valued cell or byte, or the string "false" - it doesn't really matter, > but it ought > to be efficient to process so a zero cell seems easiest. The point is that > the only code > that has to change is the interpretation of a boolean property, and the > behaviour in the > presence of old code is almost the same as you got before the addition of > this facility > - that a property remains true when you would like it to be false. The > "almost" comes > from the fact that, to old code, any attempt to modify a boolean with an > overlay would > have the same effect as setting it, but since an overlay hasn't previously > been able to > set a boolean to false I don't see this as a significant difference. IIRC, there are cases where a property with any value is expected to be treated as true and in particular a value of 0 is true. So changing the interpretation globally may be a problem. Rob -- 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
