[U-Boot] libfdt: make fdt_increase_size() available to everyone

Timur Tabi timur at freescale.com
Thu May 20 13:44:52 CEST 2010


On Thu, May 20, 2010 at 3:28 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Timur Tabi,
>
> In message <4BF4623B.1080109 at freescale.com> you wrote:
>>
>> > Why would this in any way be a board specific implementation? This
>> > makes no sense to me. The feature to include some binary data into the
>> > DTB is IMO in no way dependent on or specific to a certain board.
>>
>> The data I'm trying to embed is firmware for various devices on some of our
>> SOCs, such as the QE on the MPC8360.  Only boards with SOCs that have these
>> devices come with firmware, and not all of them require the firmware to be
>> passed to Linux.
>
> Yes, I know all of this. This is your specific use case. But maybe you
> can take the blinkers off for a moment, and face up to other potential
> use cases as well?

Come on, Wolfgang.  Why do you think I posted this patch in the first
place?  I even said so in the title of patch: "make
fdt_increase_size() available to everyone".

You asked why the information would be board-specific, and I answered
that question.

Now I believe you're intentionally trying to be difficult.

> User A might want to ambed a FPGA bit stream, user B something we
> don't even dream of yet.

Which is exactly why I want fdt_increase_size() to be available to everyone.

> Instead of implementing this feature in a way that makes it restricted
> to your current use case only we can as well make it generic enough so
> others can use it as well.

Exactly!  And the best way to do that is to make the function that
adds space to the fdt available to everyone.

>> Please note that fdt_increase_size() is just a front-end to fdt_open_into(),
>> so technically I don't need to fdt_increase_size().  However, you said you
>> would reject any patch that uses fdt_open_into() in this manner, so we're
>> back to square one.
>
> Back to square one? I did not realize you ever left that position ;-)

How silly of me.  For a moment, I forgot that I was trying to improve U-Boot.

-- 
Timur Tabi
Linux kernel developer at Freescale


More information about the U-Boot mailing list