[U-Boot] [PATCH v3 6/6] fdt: add decode helper library

Simon Glass sjg at chromium.org
Fri Oct 14 20:21:54 CEST 2011


Hi Kumar,

On Fri, Oct 14, 2011 at 11:12 AM, Kumar Gala <galak at kernel.crashing.org> wrote:
>
> On Oct 11, 2011, at 5:26 PM, Simon Glass wrote:
>
>> This library provides useful functions to drivers which want to use
>> the fdt to control their operation. Functions are provided to:
>>
>> - look up and enumerate a device type (for example assigning i2c bus 0,
>> i2c bus 1, etc.)
>> - decode basic types from the fdt, like addresses and integers
>>
>> While this library is not strictly necessary, it helps to minimise the
>> changes to a driver, in order to make it work under fdt control. Less
>> code is required, and so the barrier to switch drivers over is lower.
>>
>> Additional functions to read arrays and GPIOs could be made available
>> here also.
>>
>> Signed-off-by: Simon Glass <sjg at chromium.org>
>> ---
>> Changes in v2:
>> - Add example proposed decode helper library
>>
>> Changes in v3:
>> - Simplify decode library to remove provide only primitive functions
>> - Remove i2c decode function
>> - Rename fdt_decode to fdtdec, since it will be used a lot
>> - Moved fdt_decode.c to /lib
>> - Export almost all functions from fdtdec, to allow widespread use
>> - Remove use of FDT_ERR_MISSING which is not strictly needed now
>>
>> include/fdtdec.h |  122 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> lib/Makefile     |    1 +
>> lib/fdtdec.c     |  131 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 254 insertions(+), 0 deletions(-)
>> create mode 100644 include/fdtdec.h
>> create mode 100644 lib/fdtdec.c
>
> I think this is the wrong approach.  If we intend to go down the path of embedded a device tree we should look at produce a live tree structure that can be used like Linux has.

The intent of this patch set is to provide U-Boot with a simple
run-time configuration system.

Can you please explain why you want a live tree for use by U-Boot?
U-Boot already has one that it passes on to Linux, and this is under
control of scripts, etc., quite separate from this.

This fdt is for configuration of devices used by U-Boot itself.

What can U-Boot find out that it would want to put into this private
fdt? Are you thinking of probing for devices early on and then using
them later in U-Boot? If so, surely no code can exist which does this
now, since this patch set is new.

>
> There are a lot of places we are manipulate device tree blobs that would be more efficient if we had a live tree structure in place.

Please can you point to these? Are you sure you are not referring to
the working_fdt? As I understand it this is already a live structure.

>
> I think that will only get worse with the addition of embedding a tree.

I need a bit more info / understanding before I can respond to this
email properly.

Regards,
Simon

>
> - k
>
>


More information about the U-Boot mailing list