On Thu, May 20, 2010 at 3:28 AM, Wolfgang Denk wd@denx.de wrote:
Dear Timur Tabi,
In message 4BF4623B.1080109@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.