[PATCH v2 3/6] Add fdtget utility to read property values from device tree

Simon Glass sjg at chromium.org
Sat Sep 17 02:25:10 EST 2011


Hi David,

On Fri, Sep 16, 2011 at 1:18 AM, David Gibson
<david at gibson.dropbear.id.au> wrote:
> On Sun, Sep 11, 2011 at 09:34:01PM -0700, Simon Glass wrote:
>> Hi David,
>>
>> Thanks for your comments.
>
> [snip]
>> >> > B) What to do when the property just doesn't fit into that format -
>> >> > either it's length is not a multiple of the fixed integer size, or
>> >> > it's not NUL-terminated for "s".  Obviously some kind of error is in
>> >> > order, but in case A2 above, do we *just* error, or print what we can
>> >> > before giving up.
>> >>
>> >> Prefer to error since any output might be confusing. But I will take a
>> >> look to make sure that is easy to do.
>> >
>> > It is trivial to check in advance for the existing types - for
>> > integers just check if the property has length a multiple of the
>> > integer size, for strings check if the last byte is '\0'.  Well.. then
>> > it depends a bit on how safe you want "s" to be - do you check for
>> > reasonably printable characters first or not.  How easy it is to
>> > pre-check for possible future types is not neccessarily obvious of
>> > course.
>>
>> Yes I have added a check for (length % size) == 0. For strings I don't
>> think we should be picky so long as there is a NUL terminator. If you
>> don't specify a type, the utility already tries to guess, and will
>> fall back to integer or even byte if it finds the string has ctrl
>> characters. When the user says -ts I think we need to try hard to
>> obey. I can't think of any reason to store strange characters in a
>> string property, but others might.
>
> Yes, that makes sense.  One reason for funny bytes in a string that
> springs to mind would be inclusion of UTF-8 or other high-bit
> character encodings.
>
> One useful extension of what you have now might be to add a "raw
> binary" format.  Not much use for humans, but could be handy for
> scripts extracting blobs from the device tree.  In fact, using the
> same interpretation of existing printf() descriptors, that would
> actually be equivalent to 'c'.

Yes I was thinking about how to do that as it might be useful. I think
'c' makes perfect sense. Will add to the todo.

Regards,
Simon

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


More information about the devicetree-discuss mailing list