A number of style fixes across the files in this directory, including:
* Correct invalid kernel-doc content.
* Tidy up massive comment in fdt_region.c.
* Use correct spelling of "U-Boot".
* Replace tests of "! <var>" with "!<var>".
* Replace "libfdt_env.h" with <libfdt_env.h>.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Acked-by: Simon Glass <sjg@chromium.org>
Currently, this function returns a positive value on error,
so we never know whether this function has succeeded or failed.
For example, if the given property is not found, fdt_getprop()
returns -FDT_ERR_NOTFOUND, and then this function inverts it,
i.e., returns FDT_ERR_NOTFOUND (=1).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Fixes: bc4147ab2d ("fdt: Add a function to count strings")
Acked-by: Simon Glass <sjg@chromium.org>
As mentioned in the comment block in include/libfdt.h,
fdt_get_string_index() is supposed to return a negative value
on error.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Fixes: 5094eb408a ("fdt: Add functions to retrieve strings")
Acked-by: Simon Glass <sjg@chromium.org>
After syncing the sunxi dts files with the upstream kernel dm/fdt sunxi
builds would no longer boot.
The problem is that stdout-path is now set like this in the upstream dts
files: stdout-path = "serial0:115200n8". The use of options in of-paths,
either after an alias name, or after a full path, e.g. stdout-path =
"/soc@01c00000/serial@01c28000:115200", is standard of usage, but something
which the u-boot dts code so far did not handle.
This commit fixes this, adding support for both path formats.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>
Given a device tree node, a property name and an index, the new function
fdt_get_string_index() will return in an output argument a pointer to
the index'th string in the property's value.
The fdt_get_string() is a shortcut for the above with the index being 0.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Given a device tree node and a property name, the new fdt_find_string()
function will look up a given string in the string list contained in the
property's value and return its index.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Given a device tree node and a property name, the fdt_count_strings()
function counts the number of strings found in the property value.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
It has been observed that fit_check_format() will fail when passed a
corrupt FIT image. This was tracked down to _fdt_string_eq():
return (strlen(p) == len) && (memcmp(p, s, len) == 0);
In the case of a corrupt FIT image one can't depend on 'p' being NULL
terminated. I changed it to use strnlen() to fix the issue.
Signed-off-by: Tom Rini <trini@ti.com>
This function is useful outside libfdt, so export it.
Ref: DTC commit b7aa300e
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
commit 142419e "dtc/libfdt: sparse fixes", for u-boot's libfdt copy.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Jerry Van Baren <gvb.uboot@gmail.com>
For ages, we've been talking about adding functions to libfdt to allow
iteration through properties. So, finally, here are some.
I got bogged down on this for a long time because I didn't want to
expose offsets directly to properties to the callers. But without
that, attempting to make reasonable iteration functions just became
horrible. So eventually, I settled on an interface which does now
expose property offsets. fdt_first_property_offset() and
fdt_next_property_offset() are used to step through the offsets of the
properties starting from a particularly node offset. The details of
the property at each offset can then be retrieved with either
fdt_get_property_by_offset() or fdt_getprop_by_offset() which have
interfaces similar to fdt_get_property() and fdt_getprop()
respectively.
No explicit testcases are included, but we do use the new functions to
reimplement the existing fdt_get_property() function.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This was extracted from the DTC commit:
73dca9ae0b9abe6924ba640164ecce9f8df69c5a Mon Sep 17 00:00:00 2001
Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>
Currently, the Linux kernel, libfdt and dtc, when using flattened
device trees encode a node's phandle into a property named
"linux,phandle". The ePAPR specification, however - aiming as it is
to not be a Linux specific spec - requires that phandles be encoded in
a property named simply "phandle".
This patch adds support for this newer approach to dtc and libfdt.
Specifically:
- fdt_get_phandle() will now return the correct phandle if it
is supplied in either of these properties
- fdt_node_offset_by_phandle() will correctly find a node with
the given phandle encoded in either property.
- By default, when auto-generating phandles, dtc will encode
it into both properties for maximum compatibility. A new -H
option allows either only old-style or only new-style
properties to be generated.
- If phandle properties are explicitly supplied in the dts
file, dtc will not auto-generate ones in the alternate format.
- If both properties are supplied, dtc will check that they
have the same value.
- Some existing testcases are updated to use a mix of old and
new-style phandles, partially testing the changes.
- A new phandle_format test further tests the libfdt support,
and the -H option.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This was extracted from the DTC commit:
d75b33af676d0beac8398651a7f09037555a550b Mon Sep 17 00:00:00 2001
Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>
