Re: RFC: Encoding property deletion in FDT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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.

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?

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



[Index of Archives]     [Device Tree]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux