Patchwork [U-Boot,02/14] fdt: Add functions to access phandles, arrays and bools

login
register
mail settings
Submitter Simon Glass
Date Nov. 24, 2011, 3:54 a.m.
Message ID <1322106896-23054-3-git-send-email-sjg@chromium.org>
Download mbox | patch
Permalink /patch/127423/
State New, archived
Headers show

Comments

Simon Glass - Nov. 24, 2011, 3:54 a.m.
Add a function to lookup a property which is a phandle in a node, and
another to read a fixed-length integer array from an fdt property.
Also add a function to read boolean properties.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/fdtdec.h |   40 ++++++++++++++++++++++++++
 lib/fdtdec.c     |   82 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 122 insertions(+), 0 deletions(-)
Stephen Warren - Nov. 28, 2011, 6:41 p.m.
On 11/23/2011 08:54 PM, Simon Glass wrote:
> Add a function to lookup a property which is a phandle in a node, and
> another to read a fixed-length integer array from an fdt property.
> Also add a function to read boolean properties.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Looking at the U-Boot custodians web page, you need to send the core DT
changes (well, probably anything DT related) to Jerry Van Baren.

> +/**
> + * Look up a property in a node and return its contents in an integer
> + * array of given length. The property must have at least enough data for
> + * the array (4*count bytes). It may have more, but this will be ignored.
> + *
> + * @param blob		FDT blob
> + * @param node		node to examine
> + * @param prop_name	name of property to find
> + * @param array		array to fill with data
> + * @param count		number of array elements
> + * @return 0 if ok, or -FDT_ERR_NOTFOUND if the property is not found,
> + *		or -FDT_ERR_BADLAYOUT if not enough data
> + */
> +int fdtdec_get_int_array(const void *blob, int node, const char *prop_name,
> +		int *array, int count);

The kernel's equivalent of this function retrieves an array of U32s. Is
one version more correct than the other?

> +/**
> + * Look up a boolean property in a node and return it.
> + *
> + * A boolean properly is true if present in the device tree and false if not
> + * present, or present with a 0 value.
> + *
> + * @param blob	FDT blob
> + * @param node	node to examine
> + * @param prop_name	name of property to find
> + * @return 1 if the properly is present; 0 if it isn't present or is 0
> + */
> +int fdtdec_get_bool(const void *blob, int node, const char *prop_name);

Does U-Boot allow use of the "bool" type here?


> +/**
> + * Look up a property in a node and check that it has a minimum length.
> + *
> + * @param blob		FDT blob
> + * @param node		node to examine
> + * @param prop_name	name of property to find
> + * @param min_len	minimum property length in bytes
> + * @param err		0 if ok, or -FDT_ERR_NOTFOUND if the property is not
> +			found, or -FDT_ERR_BADLAYOUT if not enough data
> + * @return pointer to cell, which is only valid if err == 0
> + */
> +static const void *get_prop_len(const void *blob, int node,
> +		const char *prop_name, int min_len, int *err)

Based on the function name, I'd expect it to return the length of the
property; perhaps get_prop_check_min_len?

> +/**
> + * Look up a boolean property in a node and return it.
> + *
> + * A boolean properly is true if present in the device tree and false if not
> + * present, or present with a 0 value.
> + *
> + * @param blob	FDT blob
> + * @param node	node to examine
> + * @param prop_name	name of property to find
> + * @return 1 if the properly is present; 0 if it isn't present or is 0
> + */
> +int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
> +{
> +	const s32 *cell;
> +	int len;
> +
> +	debug("%s: %s\n", __func__, prop_name);
> +	cell = fdt_getprop(blob, node, prop_name, &len);
> +	if (!cell)
> +		return 0;
> +	if (len >= sizeof(u32) && *cell == 0)
> +		return 0;
> +
> +	return 1;
> +}

In the kernel, I believe that property existence is all that's usually
checked. Is that wrong? Did the definition of a boolean property's value
in the function description above come from the specification? If a
property had a length of 0/1/2/3 with a zero value, it seems very odd to
treat that as true.
David Gibson - Nov. 29, 2011, 5:12 a.m.
On Mon, Nov 28, 2011 at 11:41:32AM -0700, Stephen Warren wrote:
> On 11/23/2011 08:54 PM, Simon Glass wrote:
> > Add a function to lookup a property which is a phandle in a node, and
> > another to read a fixed-length integer array from an fdt property.
> > Also add a function to read boolean properties.
> > 
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> 
> Looking at the U-Boot custodians web page, you need to send the core DT
> changes (well, probably anything DT related) to Jerry Van Baren.
> 
> > +/**
> > + * Look up a property in a node and return its contents in an integer
> > + * array of given length. The property must have at least enough data for
> > + * the array (4*count bytes). It may have more, but this will be ignored.
> > + *
> > + * @param blob		FDT blob
> > + * @param node		node to examine
> > + * @param prop_name	name of property to find
> > + * @param array		array to fill with data
> > + * @param count		number of array elements
> > + * @return 0 if ok, or -FDT_ERR_NOTFOUND if the property is not found,
> > + *		or -FDT_ERR_BADLAYOUT if not enough data
> > + */
> > +int fdtdec_get_int_array(const void *blob, int node, const char *prop_name,
> > +		int *array, int count);
> 
> The kernel's equivalent of this function retrieves an array of U32s. Is
> one version more correct than the other?

Using u32 is a better idea.  The property formats are all defined in
terms of fixed width elements, so using a vague width type like int to
interact with it is a bad idea.
Simon Glass - Dec. 2, 2011, 1:01 a.m.
Hi Stephen,

On Mon, Nov 28, 2011 at 10:41 AM, Stephen Warren <swarren@nvidia.com> wrote:
> On 11/23/2011 08:54 PM, Simon Glass wrote:
>> Add a function to lookup a property which is a phandle in a node, and
>> another to read a fixed-length integer array from an fdt property.
>> Also add a function to read boolean properties.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>
> Looking at the U-Boot custodians web page, you need to send the core DT
> changes (well, probably anything DT related) to Jerry Van Baren.

Yes the tag was there but not picked up as I didn't have Mike's alias
file in my tree. Will fix.

>
>> +/**
>> + * Look up a property in a node and return its contents in an integer
>> + * array of given length. The property must have at least enough data for
>> + * the array (4*count bytes). It may have more, but this will be ignored.
>> + *
>> + * @param blob               FDT blob
>> + * @param node               node to examine
>> + * @param prop_name  name of property to find
>> + * @param array              array to fill with data
>> + * @param count              number of array elements
>> + * @return 0 if ok, or -FDT_ERR_NOTFOUND if the property is not found,
>> + *           or -FDT_ERR_BADLAYOUT if not enough data
>> + */
>> +int fdtdec_get_int_array(const void *blob, int node, const char *prop_name,
>> +             int *array, int count);
>
> The kernel's equivalent of this function retrieves an array of U32s. Is
> one version more correct than the other?

I would prefer to have signed, but I will change it to use u32 *.

>
>> +/**
>> + * Look up a boolean property in a node and return it.
>> + *
>> + * A boolean properly is true if present in the device tree and false if not
>> + * present, or present with a 0 value.
>> + *
>> + * @param blob       FDT blob
>> + * @param node       node to examine
>> + * @param prop_name  name of property to find
>> + * @return 1 if the properly is present; 0 if it isn't present or is 0
>> + */
>> +int fdtdec_get_bool(const void *blob, int node, const char *prop_name);
>
> Does U-Boot allow use of the "bool" type here?

Which bool type? It is returning an int.

>
>
>> +/**
>> + * Look up a property in a node and check that it has a minimum length.
>> + *
>> + * @param blob               FDT blob
>> + * @param node               node to examine
>> + * @param prop_name  name of property to find
>> + * @param min_len    minimum property length in bytes
>> + * @param err                0 if ok, or -FDT_ERR_NOTFOUND if the property is not
>> +                     found, or -FDT_ERR_BADLAYOUT if not enough data
>> + * @return pointer to cell, which is only valid if err == 0
>> + */
>> +static const void *get_prop_len(const void *blob, int node,
>> +             const char *prop_name, int min_len, int *err)
>
> Based on the function name, I'd expect it to return the length of the
> property; perhaps get_prop_check_min_len?

Changed, thanks.
>
>> +/**
>> + * Look up a boolean property in a node and return it.
>> + *
>> + * A boolean properly is true if present in the device tree and false if not
>> + * present, or present with a 0 value.
>> + *
>> + * @param blob       FDT blob
>> + * @param node       node to examine
>> + * @param prop_name  name of property to find
>> + * @return 1 if the properly is present; 0 if it isn't present or is 0
>> + */
>> +int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
>> +{
>> +     const s32 *cell;
>> +     int len;
>> +
>> +     debug("%s: %s\n", __func__, prop_name);
>> +     cell = fdt_getprop(blob, node, prop_name, &len);
>> +     if (!cell)
>> +             return 0;
>> +     if (len >= sizeof(u32) && *cell == 0)
>> +             return 0;
>> +
>> +     return 1;
>> +}
>
> In the kernel, I believe that property existence is all that's usually
> checked. Is that wrong? Did the definition of a boolean property's value
> in the function description above come from the specification? If a
> property had a length of 0/1/2/3 with a zero value, it seems very odd to
> treat that as true.

It is useful to be able to set the value to 0 or 1 (with fdtget/put),
rather than remove or add the property. A value with a length of less
than one cell is considered illegal here.

The basic idea is that the presence of the property means that it is
'true'. If it happens to have a value, then we allow that to specify
'false' if it is zero.

Thoughts?

Regards,
Simon

>
> --
> nvpublic
>
Jerry Van Baren - Dec. 2, 2011, 3:33 a.m.
On 11/28/2011 01:41 PM, Stephen Warren wrote:
> On 11/23/2011 08:54 PM, Simon Glass wrote:
>> Add a function to lookup a property which is a phandle in a node, and
>> another to read a fixed-length integer array from an fdt property.
>> Also add a function to read boolean properties.
>>
>> Signed-off-by: Simon Glass<sjg@chromium.org>
>
> Looking at the U-Boot custodians web page, you need to send the core DT
> changes (well, probably anything DT related) to Jerry Van Baren.

Yeah, I saw the patch go by.  I did not recognize the file it patched 
and looked at the history:

commit b5220bc6ed6e6a197adf4926958dca1df4b420b0
Author: Simon Glass <sjg@chromium.org>
Date:   Mon Oct 24 19:15:32 2011 +0000

     fdt: add decode helper library

     This library provides useful functions to drivers which want to use
     the fdt to control their operation. Functions are provided to:
     :
     :

and the copyright is "Copyright (c) 2011 The Chromium OS Authors."

FDT helper functions have been accumulating in common/fdt_support.c 
rather than a separate file.  Simon, what is the history of 
lib/fdtdec.c?  Is it a shared file from the linux kernel?  If it is 
u-boot specific, it would probably be better to add the functions to 
fdt_support.c.

In the same vein, I also have not looked at the functions provided by 
fdtdec.c to see if there is any overlap with existing fdt_support.c 
functions (a quick look says not).

Best regards,
gvb

[snip]
Simon Glass - Dec. 2, 2011, 4:58 a.m.
Hi Jerry,

On Thu, Dec 1, 2011 at 7:33 PM, Jerry Van Baren <gvb.uboot@gmail.com> wrote:
> On 11/28/2011 01:41 PM, Stephen Warren wrote:
>>
>> On 11/23/2011 08:54 PM, Simon Glass wrote:
>>>
>>> Add a function to lookup a property which is a phandle in a node, and
>>> another to read a fixed-length integer array from an fdt property.
>>> Also add a function to read boolean properties.
>>>
>>> Signed-off-by: Simon Glass<sjg@chromium.org>
>>
>> Looking at the U-Boot custodians web page, you need to send the core DT
>> changes (well, probably anything DT related) to Jerry Van Baren.
>
> Yeah, I saw the patch go by.  I did not recognize the file it patched and
> looked at the history:
>
> commit b5220bc6ed6e6a197adf4926958dca1df4b420b0
> Author: Simon Glass <sjg@chromium.org>
> Date:   Mon Oct 24 19:15:32 2011 +0000
>
>    fdt: add decode helper library
>
>    This library provides useful functions to drivers which want to use
>    the fdt to control their operation. Functions are provided to:
>    :
>    :
>
> and the copyright is "Copyright (c) 2011 The Chromium OS Authors."
>
> FDT helper functions have been accumulating in common/fdt_support.c rather
> than a separate file.  Simon, what is the history of lib/fdtdec.c?  Is it a
> shared file from the linux kernel?  If it is u-boot specific, it would
> probably be better to add the functions to fdt_support.c.

There are sort-of two FDT strands within U-Boot. The main one is
support for putting together an FDT to pass to the kernel (cmd_fdt,
fdt_support), and the other is for U-Boot's own use (run-time
configuration of U-Boot, fdtdec). They both use libfdt.

I regard fdt_support as part of the former, and fdtdec (decode-only
helper functions) as part of the latter. At present when you turn on
CONFIG_OF_LIBFDT you get everything, but we could provide finer
granularity for platforms which only want to decode an FDT for
run-time config and don't want to mess with it. Since fdt_decode is
about 6KB of code that might be useful.

>
> In the same vein, I also have not looked at the functions provided by
> fdtdec.c to see if there is any overlap with existing fdt_support.c
> functions (a quick look says not).

No, they are pretty low-level. An argument could be made for them to
go into libfdt once they are stable, but we are certainly not there
yet. I have quite a few patches which add more functions for
extracting data.

Regards,
Simon

>
> Best regards,
> gvb
>
> [snip]
>
Stephen Warren - Dec. 2, 2011, 3:55 p.m.
On 12/01/2011 06:01 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Mon, Nov 28, 2011 at 10:41 AM, Stephen Warren <swarren@nvidia.com> wrote:
>> On 11/23/2011 08:54 PM, Simon Glass wrote:
>>> Add a function to lookup a property which is a phandle in a node, and
>>> another to read a fixed-length integer array from an fdt property.
>>> Also add a function to read boolean properties.
>>>
>>> Signed-off-by: Simon Glass <sjg@chromium.org>

>>> +/**
>>> + * Look up a boolean property in a node and return it.
>>> + *
>>> + * A boolean properly is true if present in the device tree and false if not
>>> + * present, or present with a 0 value.
>>> + *
>>> + * @param blob       FDT blob
>>> + * @param node       node to examine
>>> + * @param prop_name  name of property to find
>>> + * @return 1 if the properly is present; 0 if it isn't present or is 0
>>> + */
>>> +int fdtdec_get_bool(const void *blob, int node, const char *prop_name);
>>
>> Does U-Boot allow use of the "bool" type here?
> 
> Which bool type? It is returning an int.

I was asking if the return type could be changed to bool.

>>> +int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
>>> +{
>>> +     const s32 *cell;
>>> +     int len;
>>> +
>>> +     debug("%s: %s\n", __func__, prop_name);
>>> +     cell = fdt_getprop(blob, node, prop_name, &len);
>>> +     if (!cell)
>>> +             return 0;
>>> +     if (len >= sizeof(u32) && *cell == 0)
>>> +             return 0;
>>> +
>>> +     return 1;
>>> +}
>>
>> In the kernel, I believe that property existence is all that's usually
>> checked. Is that wrong? Did the definition of a boolean property's value
>> in the function description above come from the specification? If a
>> property had a length of 0/1/2/3 with a zero value, it seems very odd to
>> treat that as true.
> 
> It is useful to be able to set the value to 0 or 1 (with fdtget/put),
> rather than remove or add the property. A value with a length of less
> than one cell is considered illegal here.
> 
> The basic idea is that the presence of the property means that it is
> 'true'. If it happens to have a value, then we allow that to specify
> 'false' if it is zero.

Well, it's more up to standard device tree practice, not me. I've
certainly sent patches that used a property with 0/1 value as a bool
and received review feedback from DT experts that DT represents bools
as present/absent properties, both with no value, so I assume zero
length.
Simon Glass - Dec. 2, 2011, 4:38 p.m.
Hi Stephen,

On Fri, Dec 2, 2011 at 7:55 AM, Stephen Warren <swarren@nvidia.com> wrote:
> On 12/01/2011 06:01 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Mon, Nov 28, 2011 at 10:41 AM, Stephen Warren <swarren@nvidia.com> wrote:
>>> On 11/23/2011 08:54 PM, Simon Glass wrote:
>>>> Add a function to lookup a property which is a phandle in a node, and
>>>> another to read a fixed-length integer array from an fdt property.
>>>> Also add a function to read boolean properties.
>>>>
>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>
>>>> +/**
>>>> + * Look up a boolean property in a node and return it.
>>>> + *
>>>> + * A boolean properly is true if present in the device tree and false if not
>>>> + * present, or present with a 0 value.
>>>> + *
>>>> + * @param blob       FDT blob
>>>> + * @param node       node to examine
>>>> + * @param prop_name  name of property to find
>>>> + * @return 1 if the properly is present; 0 if it isn't present or is 0
>>>> + */
>>>> +int fdtdec_get_bool(const void *blob, int node, const char *prop_name);
>>>
>>> Does U-Boot allow use of the "bool" type here?
>>
>> Which bool type? It is returning an int.
>
> I was asking if the return type could be changed to bool.

Sorry I misunderstood -  no U-Boot does not have a bool type yet.

>
>>>> +int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
>>>> +{
>>>> +     const s32 *cell;
>>>> +     int len;
>>>> +
>>>> +     debug("%s: %s\n", __func__, prop_name);
>>>> +     cell = fdt_getprop(blob, node, prop_name, &len);
>>>> +     if (!cell)
>>>> +             return 0;
>>>> +     if (len >= sizeof(u32) && *cell == 0)
>>>> +             return 0;
>>>> +
>>>> +     return 1;
>>>> +}
>>>
>>> In the kernel, I believe that property existence is all that's usually
>>> checked. Is that wrong? Did the definition of a boolean property's value
>>> in the function description above come from the specification? If a
>>> property had a length of 0/1/2/3 with a zero value, it seems very odd to
>>> treat that as true.
>>
>> It is useful to be able to set the value to 0 or 1 (with fdtget/put),
>> rather than remove or add the property. A value with a length of less
>> than one cell is considered illegal here.
>>
>> The basic idea is that the presence of the property means that it is
>> 'true'. If it happens to have a value, then we allow that to specify
>> 'false' if it is zero.
>
> Well, it's more up to standard device tree practice, not me. I've
> certainly sent patches that used a property with 0/1 value as a bool
> and received review feedback from DT experts that DT represents bools
> as present/absent properties, both with no value, so I assume zero
> length.

Yes that is the preferred way. However, it is useful to be able to
define a meaning when the property does have a value. The value may
come into the fdt later after compilation. At that point it is easier
to change a value rather than make something present/absent. For one
thing it can be done without adjust the size of the fdt blob.

Perhaps the solution is to adjust fdtput to support boolean values
explicitly (in that it would add or remove the property based on a
command-line 0/1 value).

Still I think it is useful to support a zero value meaning false when
it is provided.

Regards,
Simon

>
> --
> nvpublic
>
Jerry Van Baren - Dec. 2, 2011, 5:22 p.m.
On 12/01/2011 11:58 PM, Simon Glass wrote:
> Hi Jerry,
>
> On Thu, Dec 1, 2011 at 7:33 PM, Jerry Van Baren<gvb.uboot@gmail.com>  wrote:

[snip]

>> FDT helper functions have been accumulating in common/fdt_support.c rather
>> than a separate file.  Simon, what is the history of lib/fdtdec.c?  Is it a
>> shared file from the linux kernel?  If it is u-boot specific, it would
>> probably be better to add the functions to fdt_support.c.
>
> There are sort-of two FDT strands within U-Boot. The main one is
> support for putting together an FDT to pass to the kernel (cmd_fdt,
> fdt_support), and the other is for U-Boot's own use (run-time
> configuration of U-Boot, fdtdec). They both use libfdt.
>
> I regard fdt_support as part of the former, and fdtdec (decode-only
> helper functions) as part of the latter. At present when you turn on
> CONFIG_OF_LIBFDT you get everything, but we could provide finer
> granularity for platforms which only want to decode an FDT for
> run-time config and don't want to mess with it. Since fdt_decode is
> about 6KB of code that might be useful.

Ahh, I see.  I have not been closely tracking the u-boot config (fdtdec) 
improvements, so I did not recognize it as being part of that effort. 
That makes sense.

Thanks,
gvb

[snip]
Simon Glass - Dec. 2, 2011, 6:12 p.m.
Hi Jerry,

On Fri, Dec 2, 2011 at 9:22 AM, Jerry Van Baren <gvb.uboot@gmail.com> wrote:
> On 12/01/2011 11:58 PM, Simon Glass wrote:
>>
>> Hi Jerry,
>>
>> On Thu, Dec 1, 2011 at 7:33 PM, Jerry Van Baren<gvb.uboot@gmail.com>
>>  wrote:
>
> [snip]
>
>>> FDT helper functions have been accumulating in common/fdt_support.c
>>> rather
>>> than a separate file.  Simon, what is the history of lib/fdtdec.c?  Is it
>>> a
>>> shared file from the linux kernel?  If it is u-boot specific, it would
>>> probably be better to add the functions to fdt_support.c.
>>
>> There are sort-of two FDT strands within U-Boot. The main one is
>> support for putting together an FDT to pass to the kernel (cmd_fdt,
>> fdt_support), and the other is for U-Boot's own use (run-time
>> configuration of U-Boot, fdtdec). They both use libfdt.
>>
>> I regard fdt_support as part of the former, and fdtdec (decode-only
>> helper functions) as part of the latter. At present when you turn on
>> CONFIG_OF_LIBFDT you get everything, but we could provide finer
>> granularity for platforms which only want to decode an FDT for
>> run-time config and don't want to mess with it. Since fdt_decode is
>> about 6KB of code that might be useful.
>
> Ahh, I see.  I have not been closely tracking the u-boot config (fdtdec)
> improvements, so I did not recognize it as being part of that effort. That
> makes sense.

You are welcome, thanks.

Regards
Simon

>
> Thanks,
> gvb
>
> [snip]
>

Patch

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 9018181..9ecb6ab 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -126,3 +126,43 @@  int fdtdec_get_is_enabled(const void *blob, int node);
  * if not.
  */
 int fdtdec_check_fdt(void);
+
+/**
+ * Look up a phandle and follow it to its node. Then return the offset
+ * of that node.
+ *
+ * @param blob		FDT blob
+ * @param node		node to examine
+ * @param prop_name	name of property to find
+ * @return node offset if found, -ve error code on error
+ */
+int fdtdec_lookup_phandle(const void *blob, int node, const char *prop_name);
+
+/**
+ * Look up a property in a node and return its contents in an integer
+ * array of given length. The property must have at least enough data for
+ * the array (4*count bytes). It may have more, but this will be ignored.
+ *
+ * @param blob		FDT blob
+ * @param node		node to examine
+ * @param prop_name	name of property to find
+ * @param array		array to fill with data
+ * @param count		number of array elements
+ * @return 0 if ok, or -FDT_ERR_NOTFOUND if the property is not found,
+ *		or -FDT_ERR_BADLAYOUT if not enough data
+ */
+int fdtdec_get_int_array(const void *blob, int node, const char *prop_name,
+		int *array, int count);
+
+/**
+ * Look up a boolean property in a node and return it.
+ *
+ * A boolean properly is true if present in the device tree and false if not
+ * present, or present with a 0 value.
+ *
+ * @param blob	FDT blob
+ * @param node	node to examine
+ * @param prop_name	name of property to find
+ * @return 1 if the properly is present; 0 if it isn't present or is 0
+ */
+int fdtdec_get_bool(const void *blob, int node, const char *prop_name);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index d1321a8..613547a 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -146,3 +146,85 @@  int fdtdec_check_fdt(void)
 			"binary or define CONFIG_OF_EMBED\n");
 	return 0;
 }
+
+int fdtdec_lookup_phandle(const void *blob, int node, const char *prop_name)
+{
+	const u32 *phandle;
+	int lookup;
+
+	phandle = fdt_getprop(blob, node, prop_name, NULL);
+	if (!phandle)
+		return -FDT_ERR_NOTFOUND;
+
+	lookup = fdt_node_offset_by_phandle(blob, fdt32_to_cpu(*phandle));
+	return lookup;
+}
+
+/**
+ * Look up a property in a node and check that it has a minimum length.
+ *
+ * @param blob		FDT blob
+ * @param node		node to examine
+ * @param prop_name	name of property to find
+ * @param min_len	minimum property length in bytes
+ * @param err		0 if ok, or -FDT_ERR_NOTFOUND if the property is not
+			found, or -FDT_ERR_BADLAYOUT if not enough data
+ * @return pointer to cell, which is only valid if err == 0
+ */
+static const void *get_prop_len(const void *blob, int node,
+		const char *prop_name, int min_len, int *err)
+{
+	const void *cell;
+	int len;
+
+	debug("%s: %s\n", __func__, prop_name);
+	cell = fdt_getprop(blob, node, prop_name, &len);
+	if (!cell)
+		*err = -FDT_ERR_NOTFOUND;
+	else if (len < min_len)
+		*err = -FDT_ERR_BADLAYOUT;
+	else
+		*err = 0;
+	return cell;
+}
+
+int fdtdec_get_int_array(const void *blob, int node, const char *prop_name,
+		int *array, int count)
+{
+	const s32 *cell;
+	int i, err = 0;
+
+	debug("%s: %s\n", __func__, prop_name);
+	cell = get_prop_len(blob, node, prop_name, sizeof(s32) * count, &err);
+	if (!err) {
+		for (i = 0; i < count; i++)
+			array[i] = fdt32_to_cpu(cell[i]);
+	}
+	return err;
+}
+
+/**
+ * Look up a boolean property in a node and return it.
+ *
+ * A boolean properly is true if present in the device tree and false if not
+ * present, or present with a 0 value.
+ *
+ * @param blob	FDT blob
+ * @param node	node to examine
+ * @param prop_name	name of property to find
+ * @return 1 if the properly is present; 0 if it isn't present or is 0
+ */
+int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
+{
+	const s32 *cell;
+	int len;
+
+	debug("%s: %s\n", __func__, prop_name);
+	cell = fdt_getprop(blob, node, prop_name, &len);
+	if (!cell)
+		return 0;
+	if (len >= sizeof(u32) && *cell == 0)
+		return 0;
+
+	return 1;
+}