Hi Jerry, On Thu, Dec 1, 2011 at 7:33 PM, Jerry Van Baren <gvb.ub...@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<s...@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 <s...@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] > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot