Re: RFC: Encoding property deletion in FDT

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



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 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

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


[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