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
