Hi,<br><br><div class="gmail_quote">On Tue, Mar 13, 2012 at 5:16 AM, Grant Likely <span dir="ltr"><<a href="mailto:grant.likely@secretlab.ca" target="_blank">grant.likely@secretlab.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Tue, 13 Mar 2012 04:17:39 +0100, Jean-Christophe PLAGNIOL-VILLARD <<a href="mailto:plagnioj@jcrosoft.com">plagnioj@jcrosoft.com</a>> wrote:<br>
> On 14:39 Mon 12 Mar , Scott Wood wrote:<br>
> > On 03/09/2012 10:36 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:<br>
> > >>>> Ugh. so any value other than 1 returns false? I think that will surprise<br>
> > >>>> most people.<br>
> > >>>><br>
> > >>>> I don't like this api or binding. If it is a bool property, then why isn't<br>
> > >>>> simply testing for the property existance sufficient?<br>
> > >>> no if you want to disable it<br>
> > >>><br>
> > >>> if a bool is define in the dtsi and want to disable it int the dts<br>
> > >>><br>
> > >>> if you we can do the the invert<br>
> > >>><br>
> > >>> if !0 => true<br>
> > >>><br>
> > >>> is-ok; => true<br>
> > >>> is-ok = <val != 0>; => true<br>
> > >>> is-ok = <0>; => false<br>
> > >><br>
> > >> This is a failure of the dtc tool, not the binding. Accepting this binding<br>
> > >> means we have to live with it for a very long time. It needs to be fixed<br>
> > >> in dtc instead so that properties can be deleted instead of only modified.<br>
> > > I understand your idea but today if you put and value in the property it's true.<br>
> > ><br>
> > > So is-ok = <0>; is true also which is illogical as in any language a boolean is<br>
> > > true (1) or false (0). When I read the property I will understand false not true<br>
> ><br>
> > You could say similar things about is-ok = "no" or is-ok = "" or is-ok =<br>
> > "I'd rather you didn't"... it's expected that violating the binding may<br>
> > produce illogical results.<br>
> today is most of the binding people use a number whe the want to be able to<br>
> delete it and it's the same in most of the promgramming language<br>
<br>
</div></div>It isn't yet a big pain point, so there isn't time pressure here. Fixing the tool<br>
is the better solution, and since the kernel carries a copy of the tool we don't<br>
need to worry about adding a feature that isn't available by the dtc packaged by<br>
a distribution.<br>
<br>
Fixing the tool is the correct thing to do.<br></blockquote><div><br></div><div>I just wanted to pick up on this thread. Now in the kernel, absence of a property indicates false, and presence indicates true. This is a kernel convention, nothing to do with the dtb format. I think it is useful to support a boolean with a non-null value which can be 0, meaning true as Jean-Christophe says.</div>
<div><br></div><div>My reasons are:</div><div><br></div><div>1. dtc does not have a way to delete a property and it isn't clear what syntax could be used there. It also seems a little brittle to delete a property in one place and define it in another (ordering? confusion when people can't work out why it has gone?). So not only can dtc not do this, but I'm not sure that it should.</div>
<div><br></div><div>2. fdtput allows updating a property. It is pretty easy to do something like 'fdtput file.dtb /node propname $value' where value is 0 or 1. To use the current binding we need to either do:</div>
<div><br></div><div>if [[ $value == 0 ]]; then</div><div> fdtput -d file.dtb /node propname # new function to delete a property?</div><div>else</div><div> fdtput file.dtb /node propname 1 </div><div>fi</div><div><br>
</div><div>or perhaps something like:</div><div><br></div><div><div> fdtput -B file.dtb /node propname ${value} </div><div><br></div><div>where -B is a new option meaning either create an empty property, or delete any property it finds, based on the value being 0 or non-zero.</div>
</div><div><br></div><div>3. Discoverability: it is nice to be able to see the possible options, even if disabled. In particular, if a boolean value is true, and you later decide with fdtput to turn it off, you effectively remove all trace of it. This could be confusing for those who are looking for available options.</div>
<div><br></div><div>Arguably these issues could be fixed if we introduced some sort of type hinting into the dtb file format, but that seems a long shot. I am not sure that modifying the tools to support this arguable odd 'present/absent' boolean binding is the right approach.</div>
<div><br></div><div>So I think Jean-Christophe's idea has significant merit.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Regards,</div><div>Simon </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
g.<br>
<br>
_______________________________________________<br>
devicetree-discuss mailing list<br>
<a href="mailto:devicetree-discuss@lists.ozlabs.org">devicetree-discuss@lists.ozlabs.org</a><br>
<a href="https://lists.ozlabs.org/listinfo/devicetree-discuss" target="_blank">https://lists.ozlabs.org/listinfo/devicetree-discuss</a><br>
</div></div></blockquote></div><br>