.../dtc/libfdt/fdt_sw.c: In function 'fdt_end_node':
.../dtc/libfdt/fdt_sw.c:81: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false

Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>

Currently, callers of fdt_next_tag() must usually follow the call with
some sort of call to fdt_offset_ptr() to verify that the blob isn't
truncated in the middle of the tag data they're going to process.
This is a bit silly, since fdt_next_tag() generally has to call
fdt_offset_ptr() on at least some of the data following the tag for
its own operation.

This patch alters fdt_next_tag() to always use fdt_offset_ptr() to
verify the data between its starting offset and the offset it returns
in nextoffset.  This simplifies fdt_get_property() which no longer has
to verify itself that the property data is all present.

At the same time, I neaten and clarify the error handling for
fdt_next_tag().  Previously, fdt_next_tag() could return -1 instead of
a tag value in some circumstances - which almost none of the callers
checked for.  Also, fdt_next_tag() could return FDT_END either because
it encountered an FDT_END tag, or because it reached the end of the
structure block - no way was provided to tell between these cases.

With this patch, fdt_next_tag() always returns FDT_END with a negative
value in nextoffset for an error.  This means the several places which
loop looking for FDT_END will still work correctly - they only need to
check for errors at the end.  The errors which fdt_next_tag() can
report are:
	- -FDT_ERR_TRUNCATED if it reached the end of the structure
	   block instead of finding a tag.

	- -FDT_BADSTRUCTURE if a bad tag was encountered, or if the
           tag data couldn't be verified with fdt_offset_ptr().

This patch also updates the callers of fdt_next_tag(), where
appropriate, to make use of the new error reporting.

Finally, the prototype for the long gone _fdt_next_tag() is removed
from libfdt_internal.h.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Currently fdt_next_node() will find the next node in the blob
regardless of whether it is above, below or at the same level in the
tree as the starting node - the depth parameter is updated to indicate
which is the case.  When a depth parameter is supplied, this patch
makes it instead terminate immediately when it finds the END_NODE tag
for a node at depth 0.  In this case it returns the offset immediately
past the END_NODE tag.

This has a couple of advantages.  First, this slightly simplifies
fdt_subnode_offset(), which no longer needs to explicitly check that
fdt_next_node()'s iteration hasn't left the starting node.  Second,
this allows fdt_next_node() to be used to implement
_fdt_node_end_offset() considerably simplifying the latter function.

The other users of fdt_next_node() either don't need to iterate out of
the starting node, or don't pass a depth parameter at all.  Any
callers that really need to iterate out of the starting node, but keep
tracking depth can do so by biasing the initial depth value.

This is a semantic change, but I think it's very unlikely to break any
existing library users.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

FDT support is used for both FIT style images and for architectures
that can pass a fdt blob to an OS (ppc, m68k, sparc).

For other architectures and boards which do not pass a fdt blob to an
OS but want to use the new uImage format, we just need FIT support.

Now we can have the 4 following configurations :

1) FIT only             CONFIG_FIT
2) fdt blob only        CONFIG_OF_LIBFDT
3) both                 CONFIG_OF_LIBFDT & CONFIG_FIT
4) none                 none

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

There's currently an off-by-one bug in fdt_subnode_offset_namelen()
which causes it to keep searching after it's finished the subnodes of
the given parent, and into the subnodes of siblings of the original
node which come after it in the tree.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Kumar has already added alias expansion to fdt_path_offset().
However, in some circumstances it may be convenient for the user of
libfdt to explicitly get the string expansion of an alias.  This patch
adds a function to do this, fdt_get_alias(), and uses it to implement
fdt_path_offset().

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Using Gcc 4.3 detected this problem:

    ../dtc/libfdt/fdt.c: In function 'fdt_next_tag':
    ../dtc/libfdt/fdt.c:82: error: assuming signed overflow does not
    occur when assuming that (X + c) < X is always false

To fix the problem, treat the offset as an unsigned int.

The problem report and proposed fix were provided
by Steve Papacharalambous <stevep@freescale.com>.

Signed-off-by: Jon Loeliger <jdl@freescale.com>

The current implementation of fdt_get_path() has a couple of bugs,
fixed by this patch.

First, contrary to its documentation, on success it returns the length
of the node's path, rather than 0.  The testcase is correspondingly
wrong, and the patch fixes this as well.

Second, in some circumstances, it will return -FDT_ERR_BADOFFSET
instead of -FDT_ERR_NOSPACE when given insufficient buffer space.
Specifically this happens when there is insufficient space even to
hold the path's second last component.  This behaviour is corrected,
and the testcase updated to check it.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

If the path doesn't start with '/' check to see if it matches some alias
under "/aliases" and substitute the matching alias value in the path
and retry the lookup.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Gerald Van Baren <vanbaren@cideas.com>

As well as fdt_subnode_offset(), libfdt includes an
fdt_subnode_offset_namelen() function that takes the subnode name to
look up not as a NUL-terminated string, but as a string with an
explicit length.  This can be useful when the caller has the name as
part of a longer string, such as a full path.

However, we don't have corresponding 'namelen' versions for
fdt_get_property() and fdt_getprop().  There are less obvious use
cases for these variants on property names, but there are
circumstances where they can be useful e.g. looking up property names
which need to be parsed from a longer string buffer such as user input
or a configuration file, or looking up an alias in a path with
IEEE1275 style aliases.

So, since it's very easy to implement such variants, this patch does
so.  The original NUL-terminated variants are, of course, implemented
in terms of the namelen versions.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>