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 Glasssjg@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]