[U-Boot] [PATCH 02/14] fdt: Add functions to access phandles, arrays and bools
Simon Glass
sjg at chromium.org
Fri Dec 2 15:58:57 EST 2011
Hi Jerry,
On Thu, Dec 1, 2011 at 7:33 PM, Jerry Van Baren <gvb.uboot at 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 at 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 at 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]
>
More information about the devicetree-discuss
mailing list