Re: Overlays and boolean properties

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]

On Tue, Nov 29, 2016 at 03:10:40PM +0200, Pantelis Antoniou wrote:
> Hi Phil,
> 
> > On Nov 29, 2016, at 15:06 , Phil Elwell <phil-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org> wrote:
> > 
> > Boolean properties are defined as being properties with no content, that
> > are true if present and false if absent. They pose a problem for DT
> > overlays, since the proposed (and widely used) overlay mechanism does
> > not allow for properties (or nodes) to be deleted; overlays can only
> > make a false property true, so boolean properties are effectively
> > monostable - once true they become immutable.
> > 
> > The standard DT syntax includes /delete-property/ and /delete-node/
> > directives that do what you would expect from their names, but that
> > facility is not available to overlays. There is no FDT node that
> > represents the deletion - the directives are acted on immediately

Uh.. only partially true.  They're acted on during the compile run,
but not during the parse.  dtc does have an internal representation of
node or property deletions that gets resolved when we combine the
fragments in the source file.
> > - so
> > we would need some extra markup - say __delete_property__ and
> > __delete_node__ - to hold the names of items to be deleted.

So, in principle this wouldn't be that hard - we'd just need to
translate dtc's internal representation into a representation in the
dtb.  That could be done with special properties, or with new opcodes
at the dtb encoding level.

> > Before I take this further, does anybody have any thoughts on the idea?

So.. the first question, is do we have a pressing use case for this?
dtbos can (apart from this) alter anything in a base tree, but doing
so isn't often a good idea.  Usually they'll just add new nodes and
properties.

> The original patchset did support removing properties (by prefixing them with -).
> 
> I can revive that if we have consensus about the format/method.

On the whole, I'd prefer not to see extensions of the existing overlay
format - instead I'd like to see focus on a new and better thought out
connector format.

-- 
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]